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I.  INTRODUCTION 


A.  MOTIVATION 

Voice  over  Internet  Protocol  (VoIP)  is  becoming  a  popular  technology. 
Currently,  three  million  households  use  VoIP.  It  is  estimated  that  the  number  will 
increase  to  twenty-seven  million  by  the  end  of  2009  [1].  Furthermore,  companies  and 
public-sector  organizations  are  expected  to  invest  over  nine  hundred  million  dollars  into 
the  VoIP  technology  in  2005,  an  increase  of  more  than  two  hundred  million  dollars 
compared  to  last  year  [2],  This  indicates  that  VoIP  continues  to  grow  in  popularity  and 
remains  a  promising  telecommunication  technology  that  will  gradually  replace  traditional 
PSTN  phone  systems. 

Integration  of  VoIP  capabilities  into  the  existing  MYSEA  architecture  is  highly 
desirable  for  both  economical  and  management  reasons.  Deploying  VoIP  greatly  reduces 
the  cost  of  making  long  distance  calls  from  the  MLS  LAN  to  an  external  network  such  as 
the  Internet.  Management  of  telephone  systems  in  the  MLS  LAN  will  also  be  simplified 
with  the  use  of  VoIP  as  rewiring  phones  for  nomadic  users  is  no  longer  needed.  Thus, 
extending  MYSEA  to  include  VoIP  is  beneficial. 

B.  PURPOSE  OF  STUDY 

This  study  is  a  preliminary  step  in  integrating  VoIP  capabilities  into  the  existing 
MYSEA  architecture.  The  objective  is  to  determine  the  feasibility  of  this  integration. 
The  current  MYSEA  environment  has  a  number  of  NAT  components  that  may  make  the 
integration  of  VoIP  into  the  MLS  environment  difficult  if  not  impossible.  A  set  of 
experiments  were  devised  and  conducted  to  test  if  VoIP  works  with  the  NAT  components 
in  MYSEA. 

C.  ORGANIZATION  OF  PAPER 

This  paper  is  organized  into  five  chapters  and  six  appendices.  A  brief 
introduction  is  provided  in  Chapter  I.  Chapter  II  provides  the  background  information 
related  to  this  research  study.  A  technical  comparison  between  two  popular  VoIP 
protocols,  H.323  and  SIP,  is  presented  in  Chapter  III.  One  of  the  two  protocols  will  be 
selected  for  testing  purposes.  Chapter  IV  describes  the  test  plan  used  to  confirm  the 


1 


feasibility  of  integrating  VoIP  capabilities  into  MYSEA.  The  problems  encountered  and 
results  from  each  test  are  also  discussed  in  this  chapter.  The  last  chapter  or  Chapter  V 
talks  about  future  work  and  conclusion. 

Six  appendices  are  also  included  in  this  paper.  Appendix  A  has  surveys  of  hard 
and  softphones.  Appendices  B  through  F  contain  descriptions,  instructions,  and  results  of 
tests  described  in  Chapter  IV. 
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II.  BACKGROUND 


This  chapter  presents  background  information  pertaining  to  this  thesis  study.  It 
includes  a  high-level  technical  overview  of  the  current  VoIP  technology.  Finally,  the 
MYSEA  architecture  is  described  in  the  last  section. 

A.  INTRODUCTION 

The  traditional  phone  system  has  been  evolving  since  the  first  voice  transmission 
in  1876  using  a  ring-down  circuit.  Today,  phone  systems  no  longer  run  on  an  analog 
network,  instead  they  use  a  digital  network  known  as  the  Public  Switched  Telephone 
Network  (PSTN).  The  PSTN  greatly  reduces  the  amount  of  noise  inflicted  by  analog 
voice  amplification  during  transmission  and  provides  number  of  services,  such  as  call 
waiting,  call  forwarding,  three-way  calling,  call  blocking,  etc.  Despite  the  benefits 
obtained  from  the  PSTN,  there  are  drawbacks  to  the  system  that  motivated  the  VoIP 
solution. 

1.  Advantages  of  VoIP 

VoIP  has  many  advantages  over  the  traditional  PSTN  phone  systems.  These 
include  the  efficient  use  of  bandwidth,  reduction  or  possible  elimination  of  long  distance 
and  phone  charges,  convergence  of  the  voice  and  data  networks,  and  advanced  features. 
Some  of  them  will  be  discussed  further  below. 

a.  Efficient  Use  of  Bandwidth 

Bandwidth  is  a  key  performance  measure  of  a  network.  It  defines  how 
many  bits  can  be  transmitted  every  second,  which  means  the  more  bandwidth  available, 
the  more  data  can  be  sent  in  a  given  period  of  time. 

PSTN  phone  system  requires  a  minimum  of  64-kbps  of  dedicated  circuit 
between  the  two  calling  devices.  The  circuit  is  reserved  for  the  entire  duration  of  the  call 
regardless  of  whether  or  not  any  data  is  in  transmission.  Hence,  bandwidth  is 
unnecessarily  wasted.  On  the  other  hand,  VoIP  uses  IP  networks  that  have  the  flexibility 
to  allocate  bandwidth  as  needed  and  reserve  the  unallocated  bandwidth  for  other  data. 
Thus,  the  use  of  network  bandwidth  in  VoIP  is  more  efficient. 


3 


b.  Reduction  or  Possibly  Elimination  of  Long  Distance  and  Phone 
Charges 

The  cost  of  a  long  distance  call  generally  depends  on  two  factors:  duration 
and  destination  of  call.  Charges  can  accumulate  when  an  enterprise  or  individual 
frequently  makes  this  type  of  call.  VoIP  service  providers  have  monthly  flat-rate  plans 
that  offer  unlimited  or  fixed-number  of  minutes  to  make  calls,  including  long  distance 
calls.  These  plans  are  much  more  economical  than  the  traditional  charge-by-minute 
service.  Thus  will  greatly  reduce  or  possibly  eliminate  the  phone  and  long  distance 
charges  for  individuals  and  enterprises  that  make  frequent  long  distance  phone  calls. 

c.  Convergence  of  Voice  and  Data  Networks 

Traditionally,  a  voice  network  only  transmits  voice  and  a  data  network 
only  carries  data.  This  is  no  longer  true.  Data  makes  up  major  traffic  on  voice  networks. 
Unlike  data  networks,  voice  networks  are  not  efficient  in  carrying  data  due  to  its 
inflexible  bandwidth  allocation  and  limited  bandwidth.  Therefore,  most  enterprises 
maintain  both  networks. 

However,  in  many  cases,  management  and  maintenance  of  two  different 
networks  has  proved  to  be  cumbersome  and  costly  for  enterprises.  Upgrading  the  voice 
network  equipment  such  as  the  Public  Branch  Exchanges  (PBX)  telephones  burdens 
enterprise  budgets.  If  VoIP  is  deployed,  the  voice  network  will  no  longer  be  needed  and 
will  leave  the  enterprise  with  only  the  data  network. 

d.  Advanced  Features 

VoIP  provides  all  the  services  of  a  traditional  phone  system  including 
speed-dial,  call  waiting,  busy  signaling,  caller-ID,  etc.  In  addition,  VoIP  can  interoperate 
with  services  traditional  phone  systems  lack  such  as  video-conferencing,  instant 
messaging,  email,  click-to-dial,  and  directory  service. 

2.  Disadvantages  of  VoIP 

While  more  home  users  and  businesses  are  in  the  transition  to  use  VoIP,  the 
technology  does  have  shortcomings.  These  will  be  discussed  in  detail  below. 

a.  Quality  of  Voice 

Voice  data  traveling  across  an  IP  network  is  highly  susceptible  to  delay 
and  loss  due  to  routing  and  network  latency.  Voice  in  analog  form  has  to  be  converted 
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and  compressed  into  digital  packets  before  transmission  over  an  IP  network.  A 
compression  method  that  aggressively  minimizes  the  size  of  voice  packets  will 
deteriorate  the  quality  of  voice.  As  a  result,  the  quality  of  voice  using  VoIP  may  be 
worse  than  that  obtained  from  PSTN  due  to  delay,  loss,  and  compression  of  the 
information. 

b.  Security 

In  many  cases,  maintaining  separate  voice  and  data  networks  can  be 
difficult  and  costly.  Convergence  of  both  networks  simplifies  management  and  greatly 
reduces  cost.  However,  convergence  leads  to  security  problems.  Voice  will  be 
vulnerable  to  the  same  attacks  as  other  data  traveling  across  an  IP  network.  Attacks 
include  interception,  modification,  spoofing,  man-in-the-middle  attacks  and  denial  of 
service. 

c.  Availability 

Making  a  VoIP  call  requires  a  connection  to  an  IP  network  through 
properly  configured  network  devices  that  are  dependent  on  a  stable  electrical  power 
supply.  Power  outage  and  connection  problems  will  prevent  an  individual  from  making 
or  receiving  a  VoIP  call. 

d.  911 

Currently,  none  of  the  VoIP  protocols  provide  information  regarding  the 
caller’s  physical  location  to  the  emergency  operator.  When  the  caller  dials  911,  there  is 
no  guarantee  the  call  will  be  routed  to  the  nearest  911  police  station.  At  the  same  time, 
the  911  operator  has  no  way  of  identifying  the  location  of  the  caller. 

B.  VOIP  OVERVIEW 

VoIP  uses  IP  or  a  packet-switched  network  as  the  data  transmission  vehicle.  A 
VoIP  system  digitizes  voice  using  an  audio  codec,  divides  the  digitized  voice  into 
packets,  and  sends  the  packets  over  an  IP  network  to  the  destination.  All  packets  are 
routed  without  a  guarantee  that  they  will  travel  the  same  path.  Unlike  a  PSTN  call,  no 
dedicated  circuit  is  ever  created  for  a  VoIP  call. 

The  exact  process  required  to  set  up  a  VoIP  call  is  dependent  on  the  VoIP 
protocol.  Two  types  of  protocols  are  necessary  to  complete  a  VoIP  call:  signaling  and 
media  transport.  A  signaling  protocol  has  the  responsibility  of  establishing  a  session 
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between  the  call  participants.  A  media  transport  protocol  specifies  the  rules  and  formats 
of  the  actual  voice  packets.  Currently,  the  Real  Time  Protocol  is  commonly  used  as  the 
media  transport  protocol  in  VoIP.  However,  there  is  a  wider  variety  of  signaling 
protocols.  VoIP  protocols  will  be  further  discussed  later  in  this  chapter. 

For  PSTN  systems,  a  phone  number  consisting  of  digits  is  used  to  locate  a  phone. 
A  phone  number  in  VoIP  can  be  a  regular  PSTN  phone  number,  an  address,  or  an  alias. 
The  “phone  number”  ultimately  is  translated  to  a  32-bit  or  128-bit  IP  address  depending 
on  whether  IPv4  or  IPv6  is  used.  Every  VoIP  signaling  protocol  must  provide  address 
resolution  capability. 

There  are  four  general  VoIP  communication  modes.  They  are  Phone-to-Phone, 
Phone -to-PC,  PC-to-Phone,  and  PC-to-PC.1  Voice  transmission  is  carried  by  both  PSTN 
and  IP  networks  under  the  first  three  modes.  A  VoIP  service  provider  that  interconnects 
the  PSTN  and  VoIP  networks  is  needed  for  the  first  three  modes  when  a  call  originates 
from  a  PSTN  network  and  arrives  at  a  VoIP  network  or  vice  versa.  Voice  travels 
exclusively  across  the  IP  network  in  the  fourth  mode. 

1.  VoIP  Phone  Overview 

VoIP  phones  generally  fall  into  three  categories:  PSTN  phones,  hardphones,  and 
softphones.  A  PSTN  phone  is  the  type  of  phone  almost  every  household  has  and  is 
connected  to  a  phone  jack  using  a  telephone  cable.  Technically,  a  PSTN  phone  in  itself 
is  not  a  VoIP  device,  but  it  can  be  used  to  make  VoIP  calls  with  the  use  of  a  phone 
adapter  known  as  the  Analog  Telephone  Adapter  (AT A)  that  converts  voice  from  analog 
to  digital  form. 

A  hardphone,  also  commonly  known  as  an  IP  phone,  can  look  identical  to  a  PSTN 
phone.  It  is  an  independent  device  that  understands  VoIP  protocols.  Unlike  a  PSTN 
phone,  a  hardphone  does  not  require  an  external  device  such  as  an  AT  A  to  make  VoIP 
calls.  All  it  needs  is  an  Internet  connection.  Table  1  lists  various  types  of  hardphones 
and  their  corresponding  descriptions  from  [3], 


1  Phone  refers  to  a  traditional  phone  and  PC  refers  to  a  personal  computer. 
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Hardphone  Type 

Description/Characteristics 

Ethernet 

Has  an  Ethernet  port 

Connects  directly  to  the  IP  network 

Cordless 

Has  IP  interface  on  base  stations 

WLAN  or  WiFi 

Has  built-in  WiFi  transceivers 

Connects  to  a  WiFi  base  station 

WLAN/WiFi  and 

Same  as  WLAN/WiFi  phones  but  can 

GSM 

also  transfer  calls  to  GSM  network 

Voice  and  Video 

Supports  for  both  voice  and  video 

1 

"able  1.  Hardphones 

A  softphone  is  a  VoIP  phone  in  the  form  of  software.  A  softphone  runs  on  a 
computing  device  such  as  a  desktop,  laptop,  or  PDA,  and  is  typically  Operating  System 
dependent.  This  type  of  phone  needs  audio  support  such  as  speakers  and  microphones 
for  communication  purposes.  Appendix  A  has  a  survey  of  hard  and  softphones. 

C.  VOIP  SERVICES 

The  VoIP  technology  is  made  up  of  four  distinct  services:  signaling,  encoding, 
transport,  and  gateway  control  [4],  A  signaling  VoIP  protocol  establishes  and  manages  a 
connection  between  the  endpoints  when  a  call  is  made.  Signaling  protocols  are  discussed 
in  Section  D.  When  the  conversation  takes  place,  voice  has  to  be  encoded  before  it  is 
transmitted  over  the  IP  network.  The  encoded  voice  packets  will  then  be  transported  via 
the  IP  network  to  the  destination.  A  gateway  may  be  needed  to  convert  voice  into 
another  format  suitable  for  the  receiving  network.  For  example,  a  gateway  will  convert 
voice  from  digital  PSTN  to  digital  IP  fonn  when  voice  packets  come  into  an  IP  network 
from  a  PSTN  network. 
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1.  Encoding 

Voice,  in  its  native  form,  cannot  be  transmitted  over  an  IP  network.  A  voice 
codec  is  used  to  convert  voice  from  analog  to  digital  data  or  digital  to  analog  data, 
compress  voice  to  optimize  bandwidth  usage,  and  packetize  the  voice  data  in  preparation 
for  transmission.  A  codec  detennines  bandwidth  usage  and  quality  of  voice.  Higher 
quality  voice  transmission  usually  requires  more  bandwidth.  The  tradeoff  between  the 
two  factors  is  critical  when  deciding  what  codec  to  use  in  VoIP  applications.  Various 
codecs  exist  to  support  VoIP.  However,  the  three  most  commonly  used  codecs  are 
G.71 1,  G.723.1,  and  G.729A.  More  infonnation  on  the  above  codec  specifications  can  be 
found  on  the  ITU-T  website. 

2.  Transport 

Media  transport  protocols  such  as  Real  Time  Protocol  (RTP)  deliver  the  encoded 
voice  packets  over  an  IP  network.  RTP  is  a  standard  developed  by  Internet  Engineering 
Task  Force  (IETF)  to  transport  real-time  audio  and  video  data.  RTP  does  not  guarantee 
reliable  transmission  of  packets.  It  usually  runs  on  top  of  UDP  due  to  the  delay- 
intolerance  of  voice  conversation  and  uses  a  dynamically  assigned  UDP  port  in  the  range 
1024-65535. 

The  RTP  Control  Protocol  (RTCP)  is  the  control  counterpart  of  RTP.  RTCP,  also 
developed  by  IETF,  is  not  required  to  be  used  with  RTP.  However,  RTCP  can  be  used  to 
monitor  transmission  performance.  End  users  in  a  VoIP  session  can  send  transmission 
statistics  in  RTCP  packets  upon  receiving  packets.  This  information  is  useful  to 
determine  network  and  delivery  performances  and  keep  track  of  retransmission  needs. 
Similar  to  RTP,  RTCP  uses  a  dynamically  assigned  UDP  port. 

3.  Gateway  Control 

A  gateway  connects  the  PSTN  and  VoIP  networks.  Voice  packets  arriving  at  its 
IP  interface  will  be  converted  by  the  gateway  from  a  format  understandable  by  IP  to  one 
that  is  understandable  by  PSTN  and  vice  versa.  A  gateway  is  necessary  for 
communications  between  Phone-to-Phone,  Phone-to-PC  and  PC-to-Phone. 

D.  VOIP  PROTOCOLS 

Table  2  lists  some  well-known  VoIP  signaling  protocols.  A  VoIP  signaling 
protocol  defines  the  fonnats  of  VoIP  messages  and  rules  for  message  exchange  necessary 
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to  establish  a  VoIP  call.  The  signaling  protocol  is  responsible  for  setting  up  a  VoIP  call, 
which  includes  tasks  like  locating  users  and  negotiating  session  parameters  between  the 
two  end  devices.  A  media  gateway  control  protocol  control  communication  amongst  the 
gateways  in  an  IP  networks. 


Protocol 

Organization 

Type 

H.323 

ITU-T 

Signaling 

Session  Initiation  Protocol  (SIP) 

IETF 

Signaling 

MGCP 

ITU-T 

Signaling 

Megaco/H.248 

ITU-T/IETF 

Signaling 

Table  2.  VoIP  Protocols 


1.  H.323 

H.323  is  an  open  standard  developed  by  ITU-T  in  1996.  H.323  was  originally 
designed  for  multimedia  conferencing  and  was  later  extended  to  support  VoIP.  H.323  is 
a  suite  of  protocols  that  provide  services  such  as  end-to-end  multipoint  conferencing, 
audio  and  video  codecs,  management  and  accounting,  and  security.  Since  1996,  the 
protocol  has  undergone  a  series  of  changes,  with  the  latest  version  (H.323v4)  providing 
many  enhanced  feature  and  services.  Refer  to  Chapter  III  for  more  details. 

2.  Session  Initiation  Protocol 

The  Session  Initiation  Protocol  is  developed  by  IETF.  It  is  an  application  protocol 
designed  to  establish  a  two-way  communication  session.  SIP  is  gaining  popularity  in  the 
VoIP  market  despite  the  fact  that  it  is  a  fairly  young  protocol  developed  in  1998.  SIP  is 
generally  more  scalable,  simple,  and  extensible  than  H.323.  Some  believe  that  SIP  will 
eventually  become  the  official  VoIP  signaling  protocol  standard.  Refer  to  Chapter  III  for 
more  details. 

3.  MGCP 

Media  Gateway  Control  Protocol  (MGCP),  developed  by  IETF,  controls 
communication  among  VoIP  gateways  in  an  IP  network.  Two  components  exist  in  the 
MGCP  architecture:  call  agents,  also  known  as  media  gateway  controller,  and  gateways. 
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MGCP  is  a  master-slave  protocol  in  which  the  master  call  agent  sends  signaling,  control, 
and  processing  commands  to  the  gateway.  The  gateway  acts  as  a  slave  and  executes  the 
commands  sent  by  the  call  agent.  MGCP  does  not  replace  SIP  or  H.323.  Rather,  the 
protocol  is  used  to  manage  signaling  and  control  activities  for  VoIP  network  gateways 
such  as  H.323,  SIP,  and  SS7  signaling. 

4.  Megaco/H.248 

Megaco/H.248,  developed  jointly  by  ITU-T  and  IETF,  has  the  same  architecture 
as  MGCP.  However,  Megaco/H.248  offers  several  advantages  over  MGCP  such  as  the 
support  of  multimedia  and  multipoint  conferencing  enhanced  services,  improved  syntax 
for  more  efficient  semantic  message  processing,  TCP  and  UDP  transport  options,  support 
for  both  text  and  binary  encoding,  and  formalized  extension  process  for  enhanced 
functionality  [5], 

E.  VOIP  CHALLENGES 

1.  Quality  of  Service 

Quality  of  Service  (QoS)  is  not  a  major  concern  in  PSTN  systems  because  a  fixed 
amount  of  bandwidth  is  dedicated  to  a  call  and  transmission  of  voice  follows  the  same 
circuit  for  the  duration  of  the  call.  On  the  other  hand,  when  a  VoIP  call  is  made,  digitized 
voice  will  be  transmitted  using  an  IP  network  that  has  no  fixed-bandwidth  allocation 
mechanism.  Thus,  it  is  subject  to  jitter,  latency,  and  packet  loss  problems,  of  which  VoIP 
is  intolerant. 

There  are  many  good  reasons  to  deploy  VoIP,  however,  it  makes  no  sense  to  use 
VoIP  if  the  quality  of  a  VoIP  call  is  lower  than  a  traditional  PSTN  phone  call.  QoS  must 
be  addressed  to  an  acceptable  level  such  that  end  users  can  carry  on  a  smooth 
conversation  with  minimal  interruptions 

2.  Security 

Security  is  another  important  aspect  of  VoIP.  Convergence  of  voice  and  data 
networks  means  that  both  voice  and  data  have  to  be  protected.  Eavesdropping  a  pure 
PSTN  phone  conversation  is  more  difficult  than  a  VoIP  conversation,  because 
interception  of  a  regular  PSTN  call  requires  physical  access  to  the  phone  lines  or 
compromise  of  the  corporate  PBX.  On  the  other  hand,  a  VoIP  conversation  can  be 
intercepted  by  an  adversary  anywhere  along  the  path  where  the  digitized  voice  packets 
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travel.  The  security  problem  is  intensified  when  sensitive  personal  information  such  as 
social  security  and  credit  card  numbers  are  given  out  over  a  VoIP  call. 

The  transmission  of  voice  over  an  IP  network  is  subject  to  security  risks.  It  is 
important  to  ensure  the  confidentiality,  integrity,  and  authenticity  of  a  VoIP  conversation 
and  availability  of  resources  when  a  VoIP  call  needs  to  be  placed.  In  summary,  the 
conversation  and  the  VoIP  network  resources  are  the  two  main  assets  that  require 
protection.  Security  mechanisms  must  be  used  to  prevent  both  internal  and  external 
eavesdropping,  spoofing,  replay,  and  denial  of  service  attacks.  Many  security 
mechanisms  such  as  encryption,  firewalls,  and  Network  Address  Translation  (NAT)  exist 
to  address  these  threats.  However,  almost  every  one  of  them  raises  problems  or  affects 
the  overall  performance  of  a  VoIP  in  some  ways. 

Encryption  effectively  protects  the  confidentiality  and  possibly  authenticity  of 
VoIP  packets  by  making  it  impossible  for  people  other  than  the  intended  recipient  to  read 
the  packets.  However,  encrypting  every  packet,  at  the  sending  end  and  decrypting  it  at 
intennediate  nodes  and  at  the  receiving  end  could  cause  an  immense  amount  of  delay, 
thus  lowering  the  QoS.  The  size  of  an  encrypted  packet  is  often  bigger  than  the  plaintext 
packet,  thus  requiring  more  bandwidth  and  leading  to  a  possibility  of  packet  drop.  This  is 
a  typical  tradeoff  between  security  and  performance. 

A  firewall  is  often  the  first  layer  of  defense  in  securing  a  network.  It  sits  between 
the  internal  and  external  network,  inspects  every  incoming  and  outgoing  packet,  and 
blocks  those  packets  that  it  thinks  is  malicious.  Firewalls  usually  inspect  packets  by 
examining  certain  fields,  such  as  IP  addresses,  ports,  and  protocol  type,  in  the  packet 
headers.  However,  some  VoIP  protocols  such  as  H.323  use  dynamic  ports  to  send  or 
receive  messages.  A  stateless  firewall  that  only  looks  at  header  information  to  determine 
packet  admissibility  might  drop  some  of  the  messages.  To  ensure  the  admission  of  those 
messages,  the  stateless  firewall  would  have  to  open  many  ports  and  leave  itself  in  a 
vulnerable  statue.  A  stateful  firewall,  one  that  stores  information  about  a  session  along 
with  previous  packet  transactions,  can  inspect  a  packet’s  application  layer  data  and  can 
manage  the  dynamic  port  problem.  However,  a  stateful  firewall  introduces  latency  due  to 
the  extensive  packet  inspection.  As  a  result,  network  performance  may  not  be  optimal. 
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Network  Address  Translation  (NAT)  is  a  method  of  mapping  a  group  of  private 
IP  addresses  to  a  group  of  public  network  IP  addresses.  NAT  conserves  IP  addresses  by 
sharing  a  limited  number  of  public  IP  addresses  among  many  internal  hosts.  A  public  IP 
address  can  be  mapped  to  multiple  internal  hosts.  Furthermore,  NAT  hides  internal  IP 
addresses  from  the  outside  world  so  that  adversaries  outside  the  network  cannot  directly 
attack  internal  hosts.  VoIP  signaling  and  media  transport  protocols  often  use  different 
ports.  Furthermore,  RTP  and  RTCP  use  random  ports  to  exchange  data,  thus 
complicating  the  NAT  process.  When  NAT  receives  the  actual  digitized  voice  packets,  it 
has  no  knowledge  of  where  to  send  it.  As  a  result,  the  packets  may  get  dropped. 

Similar  to  the  use  of  encryption,  the  use  of  firewalls  and  NAT  will  also  affect  QoS 
because  every  packet  coming  in  will  have  to  be  processed  to  determine  admission.  The 
uses  of  encryption,  firewall,  and  NAT  are  just  three  examples  of  defense  mechanisms 
against  possible  VoIP  threats.  However,  these  defenses  often  cause  problems  in  the 
operation  of  VoIP  processing  and  performance. 

F.  NAT 

Network  Address  Translation  (NAT)  is  primarily  used  for  two  purposes:  public  IP 
address  conservation  and  security.  The  advantage  of  using  NAT  is  that  any  number  of 
internal  hosts  using  un-routable  private  IP  addresses  can  be  connected  to  another 
network,  such  as  the  Internet,  using  a  small  number  of  public  IP  addresses.  When  an 
internal  host  wants  to  communicate  with  an  external  host,  NAT  maps  the  private  IP 
address  of  the  internal  host  to  one  of  its  un-used  public  IP  addresses.  The  process  of 
NAT  rewriting  the  private  IP  address  with  a  public  IP  address  in  the  source  IP  address 
field  of  all  packets  initiated  from  a  local  host  is  known  as  Source  Network  Address 
Translation  (SNAT).  Destination  Network  Address  Translation  (DNAT)  refers  to  the 
process  of  NAT  rewriting  the  public  IP  address  with  a  private  IP  address  in  the 
destination  IP  address  field  of  all  packets  received  at  its  public  interface.  Note  that  a 
NAT  device  must  have  routing  capabilities  to  route  packets  in  and  out  of  two  different 
networks.  SNAT  and  DNAT  allow  an  internal  host  to  communicate  with  an  external  host 
without  ever  exposing  its  internal  IP  address.  This  mechanism  of  hiding  internal  IP 
address  provides  another  layer  of  protection  for  system  security. 
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1.  netfilter/iptables 

Any  Linux  system  can  be  turned  into  a  NAT  device  using  netfilter  and  iptables. 
These  two  open  source  kernel  modules  are  included  in  most  Linux  distributions  that 
provide  networking  functions  including  NAT,  routing,  and  firewall.  Furthermore, 
iptables  has  a  powerful  connection  tracking  mechanism  that  allows  it  to  associate  packets 
with  their  corresponding  sessions.  This  mechanism  is  essential  in  stateful  firewalls.  More 
information  about  netfilter  and  iptables  can  be  found  at  [6].  The  next  section  describes  a 
component  in  the  MYSEA  architecture  that  uses  netfilter  to  do  NAT. 

netfilter/iptables  consults  the  nat  table  to  detennine  if  the  IP  address  and/or  port 
of  a  packet  needs  to  be  rewritten  and  how  those  fields  should  be  rewritten.  The  nat  table 
contains  three  chains  of  rules.  Two  of  them  are  PREROUTING  and  POSTROUTING. 
The  PREROUTING  chain  is  referenced  when  a  DNAT  decision  has  to  be  made  while  the 
POSTROUTING  chain  is  used  to  make  SNAT  decisions.  The  following  are  two  sample 
NAT  rules: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  192.1 68.0.1 

iptables  -t  nat  -A  PREROUTING  -iethO  -j  DNAT  -to  192.168.1.10 

The  first  rule  instructs  the  NAT  device  to  modify  the  source  IP  address  of  all 
outgoing  packets  to  192.168.0.1  after  the  packet  is  processed  by  the  routing  logic.  The 
second  rule  tells  the  NAT  device  to  rewrite  the  destination  IP  address  of  all  incoming 
packets  to  192.168.1.10  before  routing  logic  takes  place. 

2.  SIP  with  NAT 

SIP-based  VoIP  calls  rely  on  two  protocols:  SDP  for  negotiating  of  session 
parameters  and  RTP  for  transporting  of  voice  data.  Two  endpoints  setup  a  VoIP 
connection  with  exchange  of  the  INVITE  and  200  OK  messages.  Each  message  has  SDP 
information  embedded  in  the  payload  specifying  the  IP  address  the  endpoint  expects  to 
receive  RTP  voice  packets.  Before  sending  out  either  the  INVITE  or  200  OK  packet 
during  the  call  setup,  an  endpoint  located  behind  a  NAT  device  writes  its  private  IP 
address  as  part  of  the  SDP  data.  The  NAT  device,  a  layer  three  device,  performs  SNAT 
to  the  message  it  receives  from  the  endpoint  and  then  sends  the  packet  to  the  destination 
address.  Since  SDP  is  a  layer  five  protocol,  the  NAT  device  is  unable  to  examine  and 
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rewrite  the  private  IP  address  embedded  in  the  SDP  section  of  the  message.  When  the 
other  endpoint  wants  to  send  RTP  packets,  it  will  send  it  to  the  private  IP  address 
indicated  in  the  SDP  portion  of  the  received  message  and  hence  the  RTP  packets  will  get 
dropped. 

G.  MYSEA  OVERVIEW 

The  Monterey  Security  Architecture  (MYSEA)  is  a  multi-level  distributed 
operating  environment  designed  to  allow  secure  access  to  infonnation  at  different 
classifications.  MYSEA  consists  of  a  combination  of  commercial-off-the-shelf  (COTS) 
and  high  assurance  components.  The  COTS  components  are  used  to  perform  common 
user  tasks  whereas  the  high  assurance  applications  are  used  to  enforce  security  policies. 
Such  a  design  is  especially  advantageous  to  organizations  such  as  the  DoD  that  invest 
heavily  on  COTS  products  but  has  a  need  to  manage  information  with  different 
sensitivities  [7]. 

Figure  1  is  an  illustration  of  the  MYSEA  network  architecture.  Communication 
between  an  untrusted  client  on  the  MLS  LAN  and  another  client  is  mediated  by  a  MLS 
server  running  XTS-400.  The  MLS  server  enforces  security  policies  and  provides  a 
number  of  security-related  services.  Each  MLS  LAN  client  communicates  with  the 
MYSEA  server  via  an  inline  Trusted  Path  Extension  (TPE).  The  TPE  establishes  an 
encrypted  trusted  path  and  negotiates  session  level  information  with  the  MLS  server  on 
behalf  of  the  client.  Each  TPE  is  also  a  NAT  device  that  hides  the  internal  IP  address  of 
the  clients.  Currently  every  TPE  on  the  MYSEA  testbed  has  a  unique  private  IP  address 
whereas  every  client  uses  the  same  private  IP  addresses.  Refer  to  [8]  for  more  detail 
discussion  of  MYSEA. 
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Figure  1.  MYSEA  Network  Architecture  [From  Ref.  8] 


H.  SUMMARY 

This  chapter  presents  background  information  that  is  relevant  to  this  project.  To 
prepare  for  testing,  a  VoIP  protocol  must  be  selected  as  the  test  protocol.  The  next 
chapter  compares  two  popular  VoIP  protocols,  namely  H.323  and  SIP,  and  ends  with  a 
protocol  selection  for  testing. 
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III.  TECHNICAL  COMPARISON  BETWEEN  H.323  AND  SIP 


The  purpose  of  this  chapter  is  to  compare  two  dominant  VoIP  signaling  protocols: 
H.323  and  Session  Initiation  Protocol  (SIP).  At  the  end  of  the  study,  one  of  the  two 
protocols  will  be  selected  for  testing.  Selection  is  based  on  the  protocols’  simplicity  and 
flexibility,  extensibility,  scalability,  and  security.  This  chapter  consists  of  two  sections. 
The  first  section  describes  the  protocols  whereas  the  second  section  is  a  summary  of  two 
SIP  and  H.323  comparisons  presented  in  [9]  and  [10]. 

A.  H.323  AND  SIP  OVERVIEW 

H. 323  and  SIP  are  the  front-runners  in  the  VoIP  industry.  H.323  came  about  in 
1996,  two  years  before  the  birth  of  SIP  in  July  1998.  H.323  is  still  widely  used  in 
enterprises  and  continues  to  be  improved,  while  SIP  is  gaining  popularity  and  undergoes 
more  development.  The  following  subsections  present  a  high  level  overview  of  the  two 
protocols. 

I.  Background 

H.323vl  was  developed  by  ITU-U  as  a  “standard  for  real-time  video- 
conferencing  over  non-guaranteed  quality  of  service  LANs”  [9],  The  standard  has 
undergone  several  revisions.  The  latest  version,  H.323v4,  defines  basic  call  control  and 
signaling  for  multimedia  applications.  The  protocol  is  specifically  designed  to  support 
multimedia  and  voice  applications.  It  was  extended  to  support  VoIP.  The  ITU-U 
initially  concentrated  on  developing  multimedia  functionalities,  supplementary  services, 
and  internetworking  capabilities  into  H.323.  As  those  capabilities  become  standardized, 
ITU-U  works  to  address  the  protocol’s  security,  QoS,  and  mobility  issues. 

SIP,  IETF’s  standard  for  establishing  VoIP  connections,  was  standardized  in  1999 
and  revised  in  2002.  SIP  is  an  application  layer  protocol  designed  to  setup,  modify,  and 
tear  down  generic  sessions.  Other  fundamental  services  it  provides  include  user  location, 
session  invitation  and  session  negotiation.  As  with  all  IEFT  protocols,  SIP  was  not 
developed  to  support  a  particular  type  of  application.  Rather,  SIP  is  designed  to  work 
with  any  application  that  may  need  its  services.  The  IEFT  initial  focus  was  on 
standardizing  the  protocol  to  support  session  initiation.  Currently,  a  large  amount  of 
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effort  is  placed  on  defining  specific  applications,  such  as  internetworking  with  legacy 
networks  and  providing  supplementary  services  [9]. 

2.  Architecture 

Both  H.323  and  SIP  have  both  peer-to-peer  and  client-server  architectures.  H.323 
specifies  a  complete  framework  that  defines  the  protocols  and  the  message  flows  for 
multimedia  communications.  The  standard  covers  all  phases  of  a  VoIP  call  including 
set-up,  call  control,  and  media  transport.  Other  issues  critical  to  the  quality  of  a  VoIP  call 
such  as  QoS,  security,  and  mobility  are  also  addressed  in  the  standard. 

H.323  is  actually  a  suite  of  protocols  that  can  be  broken  down  into  six  classes:  call 
control  and  signaling,  audio  processing,  video  processing,  data  conferencing,  media 
transportation,  security,  and  supplementary  services.  Information  regarding  the  different 
protocols  used  in  H.323  can  be  found  in  [1 1]. 

Figure  2  depicts  the  H.323  protocol  stack.  The  lighter  colored  blocks  represent 
optional  components  whereas  the  darker  colored  blocks  represent  mandatory  components 
necessary  to  complete  a  VoIP  call.  It  is  important  to  note  that  both  H.323  and  SIP  rely  on 
the  support  of  several  common  protocols  such  as  TCP/UDP,  IP,  RTP  and  RTCP  and 
audio  processing  services.  In  summary,  only  H.245,  H.225.0/Q.931,  and  H.225.0/RAS 
are  essential  to  achieve  the  signaling  part  H.323  VoIP  call. 


Figure  2.  H.323  Protocol  Stack  [From  Ref.  9] 
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SIP  by  itself  only  defines  setup  and  teardown  of  sessions.  Advance  signaling 
features  are  specified  as  SIP  extensions.  Furthermore,  QoS  and  mobility  are  not 
addressed  by  SIP  but  can  be  supported  by  other  protocols.  SIP  depends  on  the  Session 
Description  Protocol  (SDP)  to  describe  parameters  for  multimedia  session  between  two 
endpoints.  SDP  is  a  text-based  media-description  format  that  is  carried  in  SIP  messages. 
Figure  3  depicts  the  SIP  protocol  stack.  Again,  the  darker  component  is  essential  to  the 
signaling  part  a  SIP  VoIP  call. 


Figure  3.  SIP  Protocol  Stack  [From  Ref.  9] 

3.  Components 

H.323  and  SIP  divide  functions  to  components  in  a  similar  fashion.  Basic  call 
function  controls  are  assigned  to  the  terminals  whereas  services  requiring  network 
support  are  assigned  to  network  servers.  Table  3  lists  SIP  and  H.323  network 
components  by  types. 


Client 

Servers  in  the  network 

SIP  (IETF) 

Terminal 

Proxy  server,  registrar 

Conference  server1 

Gateway12 

H.323  (ITU-T) 

Terminal 

Gatekeeper 

MCU 

Gateway 

1  Not  standardized  up  to  now.  2  Addressed  in  several  drafts,  e.g.,  SIP-T 

MCU:  Multipoint  control  unit.  Gateway;  maintains  transition  to  traditional  telephony. 


Table  3.  SIP  and  H.323  components  [From  Ref.  9] 
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An  H.323  network  consists  of  terminals  and  a  gateway.  A  gatekeeper.  Multipoint 
Control  Unit  (MCU),  and  Back  End  Service  (BES)  may  also  be  deployed  as  part  of  the 
network.  A  terminal  is  any  VoIP-enabled  device.  The  gateway  provides  translation 
services  for  terminals  that  use  different  communication  protocols  including  non- VoIP 
protocols  such  as  PSTN.  A  gatekeeper  perfonns  address  translation,  controls  accesses  of 
terminals,  manages  bandwidth  and  makes  routing  decisions.  Although  a  gatekeeper  is 
optional,  it  is  often  an  important  component  in  an  H.323  network  because  of  the  services 
it  provides.  A  H.323  network  can  have  a  MCU  that  facilitates  communication  among 
multiple  endpoints.  A  Back  End  Service  usually  exists  to  support  the  gatekeeper  by 
maintaining  information  about  endpoints  such  as  the  endpoints’  permissions, 
configurations,  and  services  [5]. 

A  SIP  network  has  endpoints,  a  proxy  server  or  redirect  server,  location  server, 
and  a  registrar.  The  registrar  authenticates  users  and  stores  location  information  from 
users.  A  proxy  server,  which  can  be  integrated  with  the  registrar,  resolves  addresses  and 
forwards  messages  on  behalf  of  the  endpoint  to  another  proxy  server  or  the  destination 
endpoint  during  call  setup  and  teardown.  The  redirect  server  performs  tasks  similar  to 
those  of  a  proxy  sever  but  instead  of  forwarding  the  message,  the  redirect  server  sends  the 
resolved  address  back  to  the  endpoint  and  lets  the  endpoint  communicate  directly  with 
the  other  endpoint.  The  location  server  supports  the  registrar  by  maintaining  location 
information  of  endpoints  [5]. 

4.  Call  Setup 

Call  setup  refers  to  the  actions  necessary  to  establish  a  connection  between  two 
endpoints.  This  process  must  be  completed  before  the  endpoints  can  exchange  actual 
voice  data.  The  following  subsections  describe  simple  H.323  and  SIP  call  setups.  The 
scenarios  assume  that  Alice  initiates  a  non-local  call  to  Bob. 

a.  H.323 

H.225.0/RAS,  Q.931  in  H.225.0,  and  H.245  are  necessary  to  establish  an 
H.323  VoIP  connection.  These  protocols  provide  functions  necessary  for  call 
registration,  call  setup,  and  capability  exchange.  Figure  4  illustrates  a  simple  H.323  call 
setup. 
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Alice 


Bob 


Gatekeeper 


1.  Call  Bob 


2.  Bob's  IP 


3.  Establish  TOP  Connection 


4.  SE1 


UP 


5.  CON 


NECT 


6.  Negotiate 


Capabilities 


Figure  4.  Simple  H.323  Call  Setup 

When  Alice  dials  Bob’s  phone  number,  (Step  1)  Alice’s  terminal  sends  a 
Registration  Admission  Request  to  the  gatekeeper  using  H.225.0/RAS.  The  gatekeeper 
registers  Alice  into  the  system,  admits  and  grants  resources  to  Alice  and  finds  Bob’s  IP 
address.  Next,  (Step  2)  the  gatekeeper  sends  the  IP  address  to  Alice.  Alice  then 
establishes  a  TCP  connection  with  Bob  at  the  IP  address  she  received  (Step  3).  Alice 
sends  a  SETUP  message  to  Bob  using  Q. 93 1/FI. 255.0,  an  ISDN-connection  control 
protocol  (Step  4).  Bob  sends  Alice  back  a  CONNECT  (Step  5)  message  to  Alice  using 
the  same  protocol  indicating  acceptance  to  the  connection.  Finally,  Alice  and  Bob 
negotiate  terminal  capabilities  using  H.245  (Step  6).  Then  H.245  will  open  logical 
channels  for  both  endpoints  to  start  the  conversation. 

b.  SIP 

Figure  5  illustrates  a  simple  SIP  call  setup.  In  this  example,  an  integration 
of  the  registrar  into  the  proxy  server  is  assumed.  Before  Alice  calls  Bob,  Alice’s  terminal 
must  register  itself  with  the  registrar  (Step  1).  This  step  is  similar  to  the  first  step  in  the 
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H.323  simple  call  setup.  After  the  registration  is  completed,  Alice  may  call  Bob  by 
sending  the  proxy  server  an  INVITE  Bob  message  (Step  2).  The  proxy  server  looks  up 
Bob’s  IP  address  and  forwards  the  invitation  to  Bob  (Step  3).  An  OK  response  will  be 
received  by  the  proxy  server  from  Bob  indicating  acceptance  to  the  call  (Step  4)  and  the 
response  will  in  turn  be  forwarded  to  Alice  (Step  5).  Throughout  this  process,  session 
parameters  and  terminal  capabilities  are  transparently  exchanged  inside  the  INVITE  and 
OK  messages  from  both  parties  using  SDP  or  some  other  methods.  From  now  on,  the 
two  parties  may  communicate  in  a  peer-to-peer  fashion. 


Alice  Proxy  Server  Bob 

1.  REGISTER 

- ► 

2.  INVITE  Bob 


3.  INVITE  Bob 


4.  OK 


5.  OK 


Figure  5.  Simple  SIP  Call  Setup 

5.  Services 

H.323  and  SIP  both  provide  basic  call  controls  as  well  as  advanced  features. 
Table  4  lists  the  features  common  to  both  protocols. 
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Feature 

H.323 

SIP 

Call  Setup 

Yes 

Yes 

Call  Teardown 

Yes 

Yes 

Call  Waiting 

Yes 

Yes 

Call  Hold 

Yes 

Yes 

Call  Transfer 

Yes 

Yes 

Call  Forwarding 

Yes 

Yes 

Call  Return 

Yes 

Yes 

Call  Identification 

Yes 

Yes 

Call  Park 

Yes 

Yes 

Capabilities  Exchange 

Yes 

Yes 

Table  4.  Basic  Call  Control  Features 


B.  H.323  AND  SIP  COMPARISON 

H.323  and  SIP  are  different  in  many  ways  despite  the  fact  that  they  provide 
similar  call  control  services  and  are  widely  used  in  VoIP  applications.  One  of  their 
fundamental  differences  lies  in  their  original  intents  and  designs.  H.323  was  designed 
with  a  focus  on  multimedia  and  voice  communications  whereas  the  SIP  design  focused 
on  providing  only  session  initiation  services.  H.323  uses  a  top-down  approach  to  specify 
a  complete  framework  for  providing  multimedia  and  voice  services.  It  is 
telecommunication-oriented  as  it  uses  existing  multimedia  protocols  in  the  ITU  H-series 
to  support  provide  various  services.  SIP,  on  the  other  hand,  uses  a  bottom-up  approach. 
Its  modular  design  allows  it  to  work  with  a  wide  range  of  applications.  SIP  takes  on  an 
Internet-oriented  design  by  adopting  a  number  of  features  from  HTTP  and  SMTP,  two  of 
the  most  successful  Internet  protocols  [9,  10]. 
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Their  implementation  approaches  lead  to  differences  in  the  simplicity  and 
flexibility,  extensibility,  scalability,  and  security  of  the  protocols.  The  following 
subsections  examine  these  differences. 

1.  Simplicity  and  Flexibility 

Simplicity  and  flexibility  are  two  important  measurements  to  detennine  the 
quality  of  the  protocols’  design.  This  subsection  compares  H.323  and  SIP  based  on  these 
two  aspects.  Protocol  specification,  message  encoding,  and  protocol  interactions  will  be 
closely  examined. 

a.  Protocol  Specification 

SIP  is  simpler  in  nature  than  H.323.  According  to  [9],  a  SIP-based  VoIP 
implementation  can  be  done  with  four  headers  (To,  From,  Call-ID,  and  Cseq)  and  three 
types  of  requests  (INVITE,  ACK,  and  BYE). 

H.323,  on  the  other  hand,  consists  of  numerous  protocols  such  as  H. 225.0 
for  call  signaling,  H.245  for  call  control,  H.332  for  conferences,  H. 450.1  to  H.450.9  for 
supplementary  services,  H.235  for  security  and  encryption,  etc.  Many  services  require  a 
number  of  H.323  protocols  to  interact  with  each  other.  This  further  intensifies  H.323 ’s 
complexity  problem  [10]. 

b.  Message  Encoding 

H.323  messages  are  encoded  by  the  ASN.l,  an  international  standard  used 
to  specify  data  used  in  communication  protocols.  Since  ASN.l  messages  exist  in  binary 
form,  a  special  tool  is  needed  to  parse  the  messages.  SIP  adopts  the  HTTP  tradition  by 
using  text-based  messages.  Hence,  SIP  messages  are  generally  easy  to  parse,  generate, 
and  debug  [10]. 

c.  Protocol  Interactions 

H.323  is  complicated  because  of  the  many  of  protocols  it  encompasses.  A 
number  of  protocols  are  often  required  for  a  single  service  in  H.323.  For  example, 
connection  establishment,  as  illustrated  in  Figure  3,  requires  Q.931/H.255.0, 
H.225.0/RAS,  and  H.245.  On  the  other  hand,  SIP  uses  a  single  INVITE  request  to 
establish  the  connection  even  though  it  depends  on  SDP  to  negotiate  session  parameters. 
H.323  also  allows  those  three  protocols  to  be  used  in  different  orders  to  establish  a 
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connection.  Thus,  network  devices  such  as  firewalls,  endpoints,  gatekeepers,  and 
gateways  must  support  and  understand  all  three  connection  establishment  methods  [12]. 

d.  Applications 

SIP  is  designed  to  create,  manage,  and  tear  down  generic  sessions.  As  a 
result,  SIP  has  the  flexibility  to  work  with  a  wide  range  of  applications.  Voice  and 
multimedia  are  just  two  applications  of  SIP.  Others  include  voice-enriched  e-commerce, 
web  page  click-to-dial,  Instant  Message,  and  IP  Centrex  services.  H.323  was  designed  to 
focus  on  a  specific  type  of  communication,  namely  voice  and  multimedia  conferencing. 
Thus,  its  applications  are  not  as  wide  as  SIP’s.  ITU-U  is  currently  working  toward 
providing  non-VoIP  services  in  H.323  [9]. 

2.  Extensibility 

Extensibility  defines  how  easy  it  is  to  add  new  features  to  the  existing  protocols. 
This  aspect  of  the  protocols  will  be  evaluated  based  on  extensible  mechanisms, 
backward-compatibility,  and  interoperability. 

a.  Extensible  Mechanisms 

Both  H.323  and  SIP  have  certain  extensible  mechanisms.  H.323  has 
nonstandardParm  fields  in  its  ASN.  1  messages.  Each  nonstandardParm  field  is  identified 
by  a  unique  vendor  code  and  the  information  contained  in  this  field  is  only  meaningful  to 
the  specific  vendor.  These  fields  allow  vendors  to  add  extensions  [10], 

SIP  adopts  the  HTTP’s  use  of  hierarchical  numeric  warning  codes.  Its 
warning  codes  are  represented  by  three  digit  numbers  where  the  first  digits  identify  which 
of  the  six  categories  the  codes  belong  to.2  The  list  of  warning  codes  can  be  easily 
extended  under  this  hierarchical  structure  system.  SIP  features  are  also  extensible.  New 
SIP  features  can  be  officially  added  by  registering  the  names  of  the  features  with  the 
Internet  Assigned  Numbers  Authority  (IANA).  New  features  will  not  cause  confusion  on 
the  server  side  because  SIP  specifies  that  a  server  shall  ignore  the  request  of  a  feature  in  a 
SIP  header  if  the  server  does  not  understand  or  support  the  feature. 


2  SIP  warning  codes  are  divided  into  six  categories:  provisional,  redirection,  request  and  server 
failure,  busy  everywhere  responses,  successful  and  bad  requests. 
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b.  Backward-Compatibility 

H.323  supports  full  backward  compatibility  among  different 
implementation  versions.  In  other  words,  obsolete  features  have  to  be  carried  over  from 
one  version  to  the  next.  Hence,  the  code  can  become  complicated.  However, 
compatibility  between  two  different  versions  of  H.323  implementations  is  guaranteed. 
On  the  other  hand,  a  new  version  of  the  SIP  implementation  does  not  need  to  support 
obsolete  features  from  past  versions.  When  an  obsolete  feature  is  requested  from  a 
server,  the  server,  by  default,  ignores  the  request,  informs  the  requestor  of  the 
unsupported  feature  and  lets  the  requestor  decide  what  to  do.  This  way,  a  SIP 
implementation  is  typically  cleaner  while  still  maintaining  some  compatibility.  Unlike 
H.323,  different  versions  of  SIP  implementation  may  suffer  from  compatibility  problems 
[10]. 

c.  Interoperability 

H.323  has  higher  interoperability  than  SIP.  H.323  has  well-defined 
implementation  guidelines  available  to  help  improve  interoperability  among  different 
H.323  vendors.  Also,  the  H.32x  family  specifies  standards  to  guarantee  interoperability 
among  circuit-switched  networks  such  as  ISDN,  B-ISDN  and  GSTN.  SIP  is  also  highly 
interoperable  with  other  protocols  due  to  its  flexibility  and  modular  design.  For  example, 
SIP  can  be  used  in  conjunction  with  H.323  where  SIP  provides  the  location  service  and 
H.323  perfonns  the  rest  of  the  communication  services.  However,  SIP  is  loosely  defined 
and  open  to  various  interpretations.  This  may  lead  to  potential  interoperability  issues. 
There  is  a  growing  effort  focused  on  addressing  interoperability  issues  in  SIP  [9]. 

3.  Scalability 

The  scalability  of  the  two  protocols,  or  the  ability  to  support  small  or  large 
volume  of  data  or  users,  is  compared  in  below.  The  design,  server  components,  and 
conference  mechanisms  of  the  protocols  will  be  evaluated  for  scalability. 

a.  Protocol  Design 

H.323  was  originally  designed  for  local  area  networks.  Addressing  in  a 
wide  area  network  (WAN)  and  user  location  were  not  initial  concerns  for  H.323.  As 
networks  employing  H.323  have  grown  in  size,  H.323  has  been  augmented  to  address 
these  issues.  However,  H.323  still  has  a  scalability  problem  because  its  loop  detection 
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algorithm  using  path  values  does  not  work  well.  SIP,  on  the  other  hand,  was  designed  to 
support  WAN  addressing  and  user  location.  It  uses  a  loop  detection  mechanism  that  is 
similar  to  the  one  employed  by  Border  Gateway  Protocol  (BGP).  Thus  unlike  H.323,  the 
SIP  loop  detection  algorithm  scales  well  [10]. 

b.  Servers 

Scalability  generally  decreases  if  servers  have  to  maintain  state  for  all 
calls.  Servers  used  in  both  protocols  can  be  stateful  or  stateless.  Endpoints  in  both 
protocols  need  to  keep  states  in  stateless  call  implementations.  Endpoints  as  well  as 
servers  need  to  maintain  states  in  stateful  call  implementation.  The  drawback  of 
maintaining  states  is  the  large  amount  of  memory  and  processing  that  is  required.  Most 
current  H.323  gatekeeper  implementations  are  designed  to  be  call  stateful  whereas  most 
SIP  proxy  implementations  are  designed  to  be  call-stateless  [12].  Therefore,  SIP  scales 
better  in  large  networks. 

c.  Conferencing 

H.323  relies  on  the  Multipoint  Control  Unit  (MCU)  to  manage  signaling  in 
multiparty  conferences  regardless  of  the  number  of  participants.  However,  MCU  can  be 
a  bottleneck  in  large  conferences.  SIP  is  more  scalable  with  regard  to  conferencing 
because  it  employs  a  distributed  control  scheme  [12]. 

4.  Security 

This  section  compares  the  security  provided  by  H.323  and  SIP  based  on  [5],  More 
specifically,  it  examines  the  protection  of  authenticity,  confidentiality,  and  integrity  for 
both  signaling  and  media  data  provided  by  H.323  and  SIP. 

a.  H.  323  Security  -H.235 

H.323 ’s  relies  on  H.235  to  specify  security  standards.  However,  H.235 
“does  not  mandate  particular  [security]  features”  [13].  To  address  interoperability  among 
different  H.235  vendors,  H.235  defines  security  profiles  corresponding  different  security 
levels.  Table  5  summaries  the  different  H.235  security  profiles  or  annexes  described  in 
[5].3 


3  H.235  Annex  A  (H.235  ASN.  1),  Annex  B  (H.323  Specific  Topics),  and  Annex  C  (H.334  Specific 
Topics)  are  not  listed  in  Table  4. 
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b.  SIP  Security 

The  SIP  standard  specifies  several  security  features  including  HTTP 
Digest  Authentication  and  S/MIME.  The  protocol  does  recommend  other  best  security 
practices  to  address  authentication,  confidentiality,  and  integrity  for  both  signaling  and 
media  data.  Table  6  lists  the  existing  SIP  security  features  presented  in  [5]. 

c.  Security  Comparison 

H.235,  the  security  protocol  for  H.323,  and  SIP  both  have 
recommendations  to  protect  the  authenticity,  confidentiality,  and  integrity  for  both 
signaling  and  media  data.  At  the  same  time,  ITU-T  and  IETF  are  making  serious  efforts 
to  address  security  problems  by  continuously  devising  new  security  recommendations. 
Even  though  H.235  has  effective  security  measures,  H.323  does  not  mandate  vendors  to 
implement  any  of  the  H.235  security  measures.  According  to  an  online  website,  not 
many  H.323  products  have  support  for  H.235  and  those  that  have  “only  use  H.235 
(baseline  security)  for  the  communication  between  gatekeeper  and  gateway  and  not  for 
communication  with  the  endpoint”  [13].  SIP,  on  the  contrary,  has  security  mechanisms 
specified  in  the  protocol  implementation  and  is  inherently  more  secure  than  H.323. 


A 


'W 
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Table  5.  H.235  Security  Profiles 
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Name 

Description 

Protection 

HTTP  Digest 

Challenge  and  response  scheme  to  protect 
si  gnaling  infbrmati  on.  Endpoints  ends  to 
server  an  MD5  hash  of  the  username, 
password,  and  nonce  provided  by  server. 

Authentication 

S/MIME 

Use  S/MIME  to  provide  protection  to 
si  gnalin  g  informati  on. 

Authentication, 

Confidentiality, 

Integrity 

RTP  and  SRTP 

Encrypt  RTP  data  defined  in  RFC  1889  or 
use  SRTP  to  protect  media  data. 

Confidentiality 

SDP 

Uses  SDP  to  carry  session  keys  for  media 
data. 

Confidentiality 

TLS 

SIP  requires  proxy  and  redirect  servers  and 
registrars  and  recommends  endpoints  to  use 
TLS  to  protect  signaling  data. 

Confidentiality, 

Integrity, 

Replav 

IPsec 

Use  IPsec  to  provide  security  for  signaling 
data  at  the  network  layer 

Authentication, 

Confidentiality, 

Integrity 

AIB 

(draft) 

Use  a  digitally-signed  message  or  message 
fragment  to  provide  authentication 

Authentication 

Authenticated 

Identity 

Management 

(draft) 

Recommends  on  howto  correctly  verify  end 
users 

Authentication 

S/M  IME  AES 
Requirement 

(draft) 

Use  AES  instead  of DES  or  3DES  as  a 
minimum  requirement  for  encryption 
implementations  of  S/M  ME  in  SIP 

Confidentiality 

Security 

Mechanism 

Agreement 

(draft) 

Provide  a  method  to  negotiate  which 
security  mechanism  to  use  between  two 
endpoints 

N/A 

End-to-Middle, 
Middle- to- 
Middle,  Middle- 
to-End  Security 

(draft) 

Describes  security  in  different  modes  of 
communication (i.e.  end-to-end, mi ddle-to- 
middle,  middle-to-end) 

N/A 

Table  6.  SIP  Security  Features 
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5.  Conclusion 

Both  protocols  have  strengths  as  well  as  weaknesses.  SIP  is  more  flexible  and 
light-weight  but  less  well-defined  compared  to  H.323.  H.323  has  a  detailed  specification 
and  offers  higher  interoperability  but  supports  fewer  applications.  Nevertheless,  H.323 
and  SIP  are  widely  used  in  VoIP  applications  and  both  are  undergoing  more  development 
to  address  their  weaknesses.  Neither  of  the  two  will  become  obsolete.  Thus, 
interoperability  between  them  will  become  necessary. 

Nevertheless,  SIP  is  simpler,  more  flexible,  extensible,  scalable,  and  can  be  more 
secure  than  H.323  based  on  the  above  comparison.  SIP,  the  younger  protocol  of  the  two, 
is  showing  the  potential  to  become  a  highly  successful  Internet  protocol.  Products  based 
on  SIP  are  becoming  increasingly  available  for  these  reasons.  For  example,  Microsoft 
has  shifted  H.323-based  NetMeeting  implementation  to  a  SIP-based  implementation  in 
Windows  XP.  Furthennore,  Microsoft  also  incorporates  a  SIP-like  protocol  stack  in  its 
.Net  framework  that  can  be  used  on  desktops  and  mobile  devices  such  as  PDAs  and  smart 
phones  [14], 4  Further  research  on  this  young  protocol  is  highly  valuable  to  the 
community,  as  the  number  of  applications  supported  by  SIP  is  expected  to  grow.  For  this 
work,  SIP  has  been  selected  for  use  in  the  experiments  described  in  Chapter  IV. 

C.  SUMMARY 

H.323  and  SIP  provide  similar  VoIP  services  using  different  approaches.  Thus 
they  differ  in  simplicity  and  flexibility,  extensibility,  scalability,  and  security.  Both 
protocols  have  advantages  as  well  as  disadvantages  and  they  continue  to  be  improved. 
For  this  project,  SIP  is  chosen  as  the  test  protocol  for  research  purposes. 


4  NetMeeting  is  standard  video-conferencing  program  included  in  Windows  2000  and  XP. 
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IV.  TESTING 


This  chapter  describes  the  test  methodology  and  test  plan  to  verify  the  feasibility 
of  SIP-based  VoIP  communications  in  different  network  architectures  that  included 
Network  Address  Translation  (NAT)  devices.  An  overview  of  the  five  tests  and  a  brief 
summary  of  the  findings  are  also  presented.  The  testing  described  in  this  chapter  is  a 
preliminary  step  in  integrating  VoIP  capabilities  into  the  existing  MYSEA  architecture. 

A.  TEST  METHODOLOGY 

Testing  is  conducted  on  a  dedicated  testbed  using  an  incremental  approach.  After 
each  test,  the  result  is  thoroughly  analyzed  before  proceeding  to  a  more  complicated  test. 
The  incremental  testing  approach  is  preferred  in  this  study  because  it  allows  easy 
identification  and  debugging  of  problems  that  emerged  during  the  tests. 

A  number  of  free  tools  are  deployed  in  the  testbed.  In  particular,  SJPhone,  a 
softphone  developed  by  SJ  Labs  [15],  is  used  to  make  and  receive  SIP-based  VoIP  calls. 
Ethereal  [16],  an  open  source  packet  capture  tool,  is  used  to  capture  packet  exchanges 
during  each  VoIP  session  for  post-testing  analysis,  netfilter  and  iptables  [6],  modules  in 
Linux  Operating  System  kernel,  provide  Network  Address  Translation  and  routing 
functions  in  the  testbed.  Finally,  Zone  Alarm  [17],  a  free  software-based  firewall,  is  used 
to  block  certain  traffic  during  the  tests. 

A  number  of  systems  are  used  to  model  the  different  components  that  make  up  the 
MYSEA  environment.  For  example,  Windows  laptops  with  SJPhone  installed  are  in  the 
testbed  to  represent  the  untrusted  clients  that  sit  behind  the  TPEs.  Linux  systems  are  used 
to  perfonn  NAT  and/or  routing  functionalities.  They  simulate  the  TPEs  in  MYSEA. 

This  project  focuses  on  testing  the  feasibility  of  making  VoIP  calls  from  the  MLS 
LAN.  Therefore,  VoIP  calls  are  always  initiated  from  the  clients  located  behind  TPEs  on 
the  MLS  LAN  to  the  clients  located  on  simulated  single  level  networks.  In  terms  of 
MYSEA,  this  is  equivalent  to  allowing  calls  to  be  initiated  from  clients  on  the  MLS  LAN 
to  clients  on  external  networks. 


31 


B.  TEST  DESCRIPTION 

The  main  objective  of  the  tests  described  in  the  following  subsections  is  to  verify 
that  VoIP  conversations  can  be  carried  out  in  each  network  configuration.  Procedures 
and  results  pertaining  to  each  test  can  be  found  in  Appendices  B,  C,  D,  E,  F,  and  G.  Note 
that  private  IP  addresses  assigned  to  network  devices  were  used  for  demonstration 
purposes  only.  However,  public  devices  such  as  public  NATs  and  routers  should  use 
public  IP  addresses  in  practical  scenarios. 

1.  Test  1:  No  NAT  VoIP  Configuration 

The  objective  of  this  experiment  is  to  observe  the  behavior  of  SJPhone  in  the 
simplest  possible  setup.  The  testbed  consists  of  two  directly  connected  VoIP-enabled 
clients  as  shown  in  Figure  6.  In  this  scenario,  Client  B  initiates  a  VoIP  call  to  Client  A. 
Test  procedures  and  results  are  included  in  Appendix  B. 


Figure  6.  Test  1:  Physical  and  Fogical  Network  Topology 

2.  Test  2:  Single  NAT  VoIP  Configuration 

The  goal  of  this  experiment  is  to  confirm  the  feasibility  of  SIP-based  VoIP  calls 
when  a  NAT  system  is  present.  The  testbed  for  this  experiment  consists  of  two  VoIP- 
enabled  clients  and  one  NAT  device  as  illustrated  in  Figure  7.  The  combination  of  the 
NAT  device  and  Client  B  simulates  the  TPE-client  pair  in  the  MYSEA  architecture. 
Client  A  is  aware  of  Client  B  in  this  setup.  Client  B,  on  the  other  hand,  is  hidden  behind 
a  NAT  device  and  is  not  visible  to  Client  A.  All  packets  exchanged  between  the  two 
clients  must  traverse  the  NAT  device  that  is  configured  with  Source  NAT  and 
Destination  NAT. 

Two  similar  tests  are  conducted  with  this  NAT  configuration.  The  first  test  has  a 
physical  and  logical  network  topology  depicted  in  Figure  7.  Even  though  the  second  test 
uses  the  same  physical  network  topology  as  the  first  test,  it  has  a  logical  topology 
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depicted  in  Figure  8.  Since  the  NAT  device  is  not  configured  to  drop  packets  destined 
for  private  IP  addresses,  Client  A  can  send  RTP  packets  directly  to  the  private  IP  address 
of  Client  B.  This  is  exactly  what  Client  A  does  based  on  the  packet  captures  provided  in 
Appendix  C.  In  non-experimental  scenarios,  a  firewall  at  the  client  is  not  necessary 
because  packets  destined  for  a  private  IP  address  will  eventually  be  dropped  as  they 
traverse  the  networks.  For  demonstration  purposes,  a  firewall  is  introduced  at  Client  A  to 
block  packets  initiated  by  Client  A  and  destined  for  Client  B.  More  information 
including  the  test  procedures  and  results  for  both  tests  can  be  found  in  Appendix  C. 


Figure  7.  Test  2:  Physical  Network  Topology  (with  and  without  firewall) 
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Figure  8.  Test  2:  Logical  Network  Topology  (with  firewall) 


3.  Test  3:  Double  NAT  VoIP  Configuration 

The  goal  of  this  experiment  is  to  confirm  the  feasibility  of  a  SIP-based  VoIP  call 
using  SJPhone  when  two  NAT  systems  are  present.  In  this  test,  a  VoIP  session  between 
two  clients  have  to  traverse  two  different  NAT  devices  as  depicted  in  Figure  9  and  Figure 
10.  Similar  to  the  previous  test,  Client  B  and  NAT  2  represent  the  client-TPE  pair  in  the 
MYSEA  architecture.  NAT  1  simulates  the  NAT  device  located  between  the  MYSEA 
network  and  the  Internet  whereas  Client  A  acts  as  a  VoIP-enabled  client  in  the  Internet. 
Both  NAT  devices  are  configured  to  perform  Source  NAT  and  Destination  NAT.  Test 
procedures  and  results  are  included  in  Appendix  D. 
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“Public  NAT' 


Figure  9.  Test  3:  Physical  Network  Topology 


“Public  NAT’ 


192.168.0.10/24  Firewall 


NAT  1 

ethO:  192.168.0.1/24 
ethl:  192.168.1.1/24 


Figure  10.  Test  3:  Logical  Network  Topology 

4.  Test  4:  Extended  Double  NAT  VoIP  Configuration 

The  purpose  of  this  experiment  is  to  confirm  that  two  different  VoIP  sessions  can 
take  place  at  different  times  when  the  sessions  have  to  traverse  a  common  public  NAT 
device.  This  and  the  next  setup  only  work  when  the  public  NAT  device  implements  a 
connection  tracking  mechanism  that  is  similar  to  what  iptables  provides.  The  test  is  setup 
so  that  the  public  NAT  device  is  not  explicitly  instructed  to  forward  packets  to  any 
specific  network.  In  other  words,  the  public  NAT  only  performs  Source  NAT  but  not 
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Destination  NAT.  A  firewall  is  installed  on  Client  A  to  prevent  Client  A  from  sending 
RTP  packets  directly  to  the  private  address  of  Client  B.  The  firewall  is  necessary  in  this 
demonstration  because  NAT  1  and  NAT  2  are  not  configured  to  drop  packets  destined  for 
private  IP  addresses. 

This  test  consists  of  three  VoIP-enabled  clients  and  three  NAT  devices  as 
depicted  in  Figures  1 1  and  12.  Two  client-TPE  pairs  are  simulated  in  this  setup,  Client  B 
and  NAT  2  being  one  pair  and  Client  A  and  NAT  3  being  the  second  pair.  NAT  1 
resembles  the  public  NAT  that  is  located  between  the  MLS  LAN  and  the  Internet.  NAT 
1  is  only  configured  with  a  SNAT  rule  whereas  NAT  2  and  NAT  3  are  configured  with 
both  SNAT  and  DNAT  rules.  The  test  proceeds  as  follows:  Client  B  initiates  a  call  to 
Client  A,  terminates  the  call,  and  then  Client  C  initiates  a  call  to  Client  A.  Procedures 
and  results  can  be  found  in  Appendix  D. 
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Figure  11.  Test  4:  Physical  Network  Topology 
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Client  A 

192.168.0.10/24 


Firewall 


I  ethl:  192.168.3.1/24 


Figure  12.  Test  4:  Logical  Network  Topology 


5.  Test  5:  Extended  Double  NAT  VoIP  Configuration  with  Simultaneous 
VoIP  Sessions 

The  purpose  of  this  test  is  to  confirm  the  feasibility  of  two  simultaneous  VoIP 
sessions  between  two  pairs  of  clients.  The  setup  of  this  test,  shown  in  Figures  13  and  14, 
closely  resembles  a  simplified  version  of  the  MYSEA  architecture.  The  IP  addresses 
used  for  different  components  in  this  demonstration  are  the  same  as  the  ones  used  in  the 
MYSEA  testbed.  This  test  consists  of  four  VoIP-enabled  clients,  three  NAT  devices,  and 
a  router.  The  router  is  introduced  here  as  a  preparation  for  the  next  test.  Refer  to  the  next 
section  for  a  description  of  the  router.  Similar  to  the  previous  test,  two  pairs  of  client- 
TPEs  are  simulated  using  Client  C,  NAT  2,  Client  D,  and  NAT  3.  Furthermore,  NAT  1  is 
not  configured  with  a  DNAT  rule  and  two  firewalls  are  installed  on  Client  A  and  Client  B 
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to  block  RTP  packets  destined  to  Client  C  and  Client,  respectively.  In  this  scenario, 
Client  C  calls  Client  A  and  Client  D  calls  Client  B  at  the  same  time. 
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Figure  13.  Test  5:  Physical  Network  Topology 


Figure  14.  Test  5:  Logical  Network  Topology 
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6.  Test  6:  MYSEA  Configuration 

The  setup  of  this  test,  illustrated  in  figures  15  and  16,  is  an  extension  to  the  last 
one  with  the  addition  of  a  MLS  server.  The  objective  of  this  test  is  to  verify  that  the  MLS 
Server  could  support  two  simultaneous  VoIP  sessions  between  two  pairs  of  clients.  Since 
the  MLS  server  does  not  perform  routing  in  the  testbed,  a  router  is  introduced  to  perform 
that  function.  The  MLS  server  simply  forwards  the  received  packets  to  the  correct 
network  interfaces  according  to  the  network  configurations.  In  this  test,  unexpected 
routing  problems  were  encountered  on  the  MLS  server.  Refer  to  the  next  section  for  a 
discussion  of  this  test. 
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Figure  15.  Test  6:  Physical  Network  Topology 
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Figure  16.  Test  6:  Logical  Network  Topology 


C.  PROBLEMS  ENCOUNTERED 

Setting  up  and  running  the  tests  was  fairly  straightforward  with  the  exception  of 
the  MYSEA  Configuration.  The  major  problem  encountered  that  ultimately  led  to  the 
failure  of  the  MYSEA  test  was  configuring  the  MLS  server  to  perform  proper  routing. 
The  MLS  server,  currently  running  XTS-400,  has  routing  limitation  such  that  only  one 
static  route  can  be  configured  for  each  network  interface.  An  attempt  to  add  a  second 
route  to  the  network  interface  X  resulted  in  the  following  error  message:  “Route 
/dev/etherX  already  exists”.  Since  every  packet  has  to  traverse  the  server,  this  limitation 
prevents  an  incoming  or  outgoing  packet  arriving  at  the  MLS  server  from  routing  to  the 
other  side  of  the  network.  According  to  the  customer  service  response  to  our  inquiry,, 
“there  is  a  known  restriction  on  [the  XTS-400]  configuration  tool  tcpip  edit  (not  the 
network  stack)  that  there  can  only  be  one  route  per  interface  device...”  [18].  Four  test 
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scenarios  were  conducted  to  ensure  that  the  MLS  server,  in  fact,  has  routing  limitation. 
Refer  to  Appendix  G  for  details.  In  conclusion,  the  MYSEA  Configuration  test  was  not 
conducted  successfully. 

D.  TEST  RESULT 

All  the  tests  described  in  the  previous  section  generate  positive  results,  i.e.  the 
results  indicate  that  VoIP  communications  are  possible  in  five  of  the  six  scenarios. 
However,  it  is  important  to  recognize  that  the  last  test  was  unsuccessful  not  because  of 
VoIP  limitation  or  the  network  topology.  Instead,  the  last  test  failed  was  due  to 
configuration  difficulties  in  the  MLS  server. 

Several  interesting  findings  are  discovered  from  analyzing  the  packet  captures. 
First,  SJPhone  will  attempt  to  send  RTP  packets  to  the  IP  address  indicated  in  the  SDP 
data.  If  that  fails,  then  SJPhone  will  resort  to  send  subsequent  RTP  packets  to  the  IP 
address  it  received  RTP  packets  from.  Second,  the  client  that  initiates  the  VoIP  call  is 
always  the  first  to  send  out  a  RTP  packet  to  the  other  party.  Third,  iptables  has  a 
connection  tracking  mechanism  that  allows  it  to  associate  incoming  packets  with 
previous  outgoing  packets  and  determine  which  VoIP  session  the  incoming  packets 
belong  to.  Since  iptables  creates  an  entry  in  its  connection  tracking  table  for  the  first 
RTP  packet  sent,  subsequent  incoming  packets  can  be  correctly  forwarded  to  the  correct 
next  hop  based  on  the  information  stored  in  the  table.  This  mechanism  plays  a  significant 
role  in  the  success  of  tests  4  and  5  where  the  public  NAT  was  not  configured  with  a 
DNAT  rule  to  forward  incoming  packets  to  any  particular  IP  addresses.  Refer  to 
Appendices  B  through  G  for  more  details  on  the  findings. 

E.  SUMMARY 

The  purposes  and  configurations  of  the  experiments  designed  for  this  feasibility 
study  are  described  in  this  Chapter.  The  results  of  the  experiments  are  also  briefly 
discussed.  The  results  are  optimistic  and  they  indicate  that  the  integration  of  VoIP  into 
MYSEA  is  possible. 
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V.  FUTURE  WORK  AND  CONCLUSIONS 


A.  FUTURE  WORK 

The  test  results  described  in  Chapter  IV  and  various  appendices  suggest  that  VoIP 
capabilities  can  be  potentially  integrated  into  the  existing  MYSEA  architecture  with  little 
effort.  However,  further  research  in  the  following  areas  is  required. 

1.  Routing  in  MLS  Server 

Every  MLS  client  communication  is  mediated  by  the  MLS  server  that  runs  on 
XTS-400,  a  high-assurance  Unix-like  system.  Unfortunately,  the  MLS  server  has  routing 
limitation  such  that  only  one  static  route  can  be  configured  for  each  network  interface. 
The  ability  to  configure  more  than  one  route  for  each  interface  in  the  MYSEA  server  is 
necessary  for  VoIP  packets  to  route  between  clients  on  the  MLS  network  and  on  external 
networks.  Therefore,  further  study  of  the  routing  configurations  or  capabilities  is 
required  to  allow  proper  routing  of  VoIP  packets. 

2.  VoIP  Conversations  Initiated  from  the  Internet 

This  research  study  is  primarily  concerned  with  testing  the  scenarios  in  which 
VoIP  conversations  are  initiated  from  the  MLS  LAN.  The  ability  for  externally  initiated 
VoIP  conversation  is  also  desirable.  Currently,  a  client  on  an  external  network  only 
knows  the  IP  address  of  the  public  NAT  device  and  there  exists  no  way  of  distinguishing 
calls  intended  for  different  clients  on  the  MLS  LAN.  In  order  for  an  internal  client  to 
receive  an  external  call,  three  features  may  have  to  be  implemented.  First,  each  internal 
client  must  own  a  unique  SIP  address  that  is  publicly  known.  This  allows  an  external 
client  to  direct  call  to  a  specific  internal  client.  Second,  a  server  must  exist  to  translate  a 
SIP  address  to  the  corresponding  internal  client  IP  address.  Third,  softphones  with 
reconfigurable  RTP  port,  such  as  the  SipXphone,  are  needed  for  each  internal  client. 
Each  client  needs  to  use  a  different  RTP  port  for  sending  and  receiving  RTP  packets  and 
the  public  NAT  must  be  configured  to  perform  port  forwarding.  This  allows  NAT  to 
forward  RTP  packets  to  the  correct  client  according  to  the  destination  port.  Research  on 
how  to  implement  this  scheme  is  highly  recommended. 
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B.  CONCLUSIONS 

The  tests  conducted  in  this  research  study  were  generally  successful. 
Furthermore,  the  test  results  indicate  that  VoIP  conversations,  at  least  in  the  scenario  we 
studied,  between  internal  and  external  clients  are  possible  even  when  various  NAT 
devices  are  present.  It  is  important  to  recognize  that  the  success  of  Test  4  and  Test  5  was 
dependent  on  the  connection  tracking  mechanism  in  iptables.  NAT  devices  without 
connection  tracking  mechanisms  were  not  tested  in  this  project.  Thus,  it  is  unknown 
whether  the  tests  will  work  if  those  devices  are  used  instead.  In  conclusion,  VoIP 
capabilities  may  be  integrated  into  the  existing  MYSEA  architecture. 
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APPENDIX  A.  A  SURVEY  OF  VOIP  HARDPHONES  AND 

SOFTPHONES 


A.  HARDPHONES 

The  following  table  is  a  survey  of  some  VoIP  hardphones.  Each  hardphone  is 
listed  with  infonnation  including  its  manufacture  (Brand/Company),  phone  type 
(category  and  Sub-Category),  the  VoIP  protocol  (VoIP  Protocol),  and  Wi-Fi  protocol 
(Wi-Fi  Protocol)  it  supports. 


Table  7.  Summary  of  Hardphones 
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B.  SOFTPHONES 

The  following  table  is  a  survey  of  some  VoIP  softphones.  Each  softphone  is 
listed  with  information  including  what  Operating  System(s)  and  VoIP  protocol(s)  (VoIP 
Protocol)  it  supports  and  whether  it  is  a  commercial  or  an  open  source  product. 
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Table  8.  Summary  of  Softphones 
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APPENDIX  B.  TEST  1:  NO  NAT  VOIP  DEMONSTRATION  USING 

SJ  PHONE 


The  instructions  in  this  appendix  describe  how  to  setup  and  demonstrate  a  SIP- 
based  VoIP  communication  between  two  directly  connected  SIP-enabled  clients  using 
SJPhone.  Figure  6  illustrates  the  physical  network  as  well  as  the  logical  topology  for  this 
demonstration.  A  VoIP  session  is  initiated  from  Client  B  to  Client  A.  Packet  captures 
from  both  clients  are  included  at  the  end  of  this  appendix  along  with  an  analysis. 

A.  Network  Topology 

Refer  to  Figure  6  for  the  physical  and  logical  network  topology. 

B.  Equipment  Requirements 
B .  1 .  Clients  A  and  B 

B .  1 . 1 .  Windows  XP  Operating  System 
B.1.2.  Soundcard 
B.1.3.  SJPhone  v.  1 .60 
B.1.4.  Ethereal 

B. 2.  Additional  Equipment 

B.2. 1 .  Cross-over  cable  to  implement  the  network  architecture  Figure  6 

B. 2.2.  Microphones  as  audio  input  devices  for  clients  A  and  B 

C.  Installation  and  Configuration 

C. l.  Client  A 

IP  Address:  192.168.0.10 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  192.168.0.20 
C.2.  Client  B 

IP  Address:  192.168.0.20 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  192.168.0.10 
C.3.  SJPhone  Installation  and  Configuration 

C. 3.1.  Client  A  and  Client  B 
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C.3. 1 . 1 .  Download  the  Windows  version  of  SJPhone  v.  1 .60  from  SJ  Labs 

C.3.1.2.  Install  SJPhone  v.  1.60 

C.3.1.3.  Launch  SJPhone 

C.3.1.4.  Right-click  on  SJPhone 

C.3.1.5.  Go  to  Services 

C.3.1.6.  Select  PC-to-PC  (SIP) 

C. 4.  Ethereal  Installation  and  Configuration 

C. 4. 1 .  Clients  A  and  B 

C.4. 1 . 1 .  Download  the  latest  Windows  version  of  Ethereal 
C  .4 . 1 .2 .  Install  Ethereal 

D.  Preparation  and  Testing 

D.  1 .  Adjust  volume  on  both  clients  accordingly 
D.2.  Plug  microphones  into  both  clients 

D.3.  On  Client  A, 

D. 3. 1 .  Launch  Ethereal 
D.3.2.  Go  to  the  Capture  menu 
D.3.3.  Go  to  Interfaces 

D.3.4.  Click  on  Capture  192.168.0.10 
D.4.  On  Client  B, 

D.4. 1 .  Launch  Ethereal 
D.4.2.  Go  to  the  Capture  menu 
D.4.3.  Go  to  Interfaces 
D.4.4.  Click  on  Capture  192.168.0.20 
D.4.5.  Call  Client  A  by  dialing  192. 168.0. 10  in  SJPhone 
D.5.  On  Client  A, 

D.5. 1 .  Select  Accept  in  the  pop-up  dialog  box  when  SJPhone  rings 
D.5.2.  Clients  A  and  B  may  engage  in  a  VoIP  conversation  at  this  point 
D.5.3.  Click  on  the  Hang-Up  bottom  on  either  SJPhone  to  tenninate  the  call 
when  finished 
D.6.  On  Clients  A  and  B, 

D.6. 1 .  Stop  packet  captures  by  selecting  Stop  on  Ethereal 
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E.  Packet  Captures 
E.  1 .  Client  A 


Figure  17  is  a  snapshot  of  the  packets  captured  on  Client  A. 


Figure  17.  Test  1 :  Packet  Capture  on  Client  A 


E.2.  Client  B 


Figure  18  is  a  snapshot  of  the  packets  captured  on  Client  B. 
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Figure  18.  Test  1 :  Packet  Capture  on  Client  B 


E.3.  Analysis 


The  packet  captures  indicate  that  as  soon  as  Client  B  initiated  a  call  to  Client  A, 
Client  B  sent  out  an  “INVITE”  message  from  192.168.0.20:5060  to  Client  A  at 
192.168.0.10:5060  (red  outline  in  Figure  17).  The  “INVITE”  message  had  embedded 
SDP  infonnation  to  inform  Client  A  that  Client  B  will  send  and  receive  RTP  voice 
packets  at  192.168.0.20  on  port  49192  (green  outline  in  Figure  17).  Client  A 
acknowledged  the  invitation  by  sending  Client  B  a  “200  OK”  message  (orange  outline  in 
Figure  18)  with  embedded  SDP  information  indicating  that  it  will  send  and  receive  RTP 
voice  packets  at  192.168.0.10  on  port  49170  (purple  outline  in  Figure  18).  Subsequent 
voice  exchanges  between  the  two  clients  were  achieved  via  192.168.0.20:  49192  on 
Client  B  and  192.16.0.10:  49170  on  Client  A  (blue  outline  in  Figure  17). 
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APPENDIX  C.  TEST  2:  SINGLE  NAT  VOIP  DEMONSTRATION 

USING  SJPHONE 


The  instructions  contained  in  this  appendix  describe  how  to  setup  and 
demonstrate  a  SIP-based  VoIP  communication  between  two  SIP-enabled  clients  via  a 
Network  Address  Translation  (NAT)  device.  In  this  setup.  Clients  A  and  B  belong  to 
different  networks  and  Client  B  is  located  behind  a  NAT  device.  The  NAT  device  is 
configured  to  act  as  a  router  and  modify  the  destination  or  source  IP  address  of  all 
packets  that  traverse  it.  In  this  scenario,  Client  B  initiates  a  VoIP  call  to  Client  A. 

The  demonstration  consists  of  two  parts.  They  are  very  similar  in  nature  except 
that  a  firewall  is  introduced  in  the  second  part.  Packet  captures  and  an  analysis  are 
included  for  each  part. 

A.  Without  Firewall 
A.  1.  Network  Topology 

Refer  to  Figure  7  for  the  physical  and  logical  network  topology. 

A.2. Equipment  Requirements 

A.2. 1 .  Client  A  and  Client  B 


A.2.1.1. 

Windows  XP  Operating  System 

A.2.1.2. 

Sound  Card 

A.2.1.3. 

SJPhone  v.  1 .60 

A.2.1.4. 

Ethereal 

A.2.1.5. 

ZoneAlann  (Client  A  only) 

A.2.2.  NAT 

A.2.2.1. 

Linux  Operating  System  (Fedora  Core  4) 

A.2.2.2. 

netfilter  and  iptables 

A.2.2. 3. 

Ethereal 
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A.2.2.4.  Two  network  cards 


A.2.3.  Additional  Equipment 

A.2.3.1.  Cross-over  cables  to  implement  the  network  architecture  illustrated 
in  Figure  7 

A.2.3.2.  Microphones  as  audio  input  devices  for  Client  A  and  Client  B 

A.2.4.  Installation  and  Configuration 

A.2.4.1.  Client  A 

IP  Address:  192.168.0.10 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  192.168.0.1 

A.2.4.2.  Client  B 

IP  Address:  192.168.0.20 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  1 92. 1 68. 1 . 1 

A.2.4. 3.  NAT 

A.2.4. 3.1 .  Configure  ethO  by  editing  /etc/sysconfig/network- 

scripts/ifcfg-ethO: 

DEVICE=eth0 
BOOTPROTO=NONE 
IPADDR=192. 168.0.1 
NETMASK=255. 255. 255.0 

A.2.4. 3. 2.  Activate  ethO  by  running: 

ifup  ethO 

A. 2. 4. 3. 3.  Configure  ethl  by  editing  /etc/sysconfig/network- 

scripts/ifcfg-eth  1 : 

DEVICE=eth1 

BOOTPROTO=NONE 
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IPADDR=192.168.1.1 


NETMASK=255. 255. 255.0 
A.2.4.3.4.  Activate  ethl  by  running: 

ifup  ethl 

A.2.4.3.5.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 
A.2.4.3.6.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
iptables  -t  nat  -F 

A.2.4.3.7.  Configure  NAT  rules  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  192.168.0.1 
iptables  -t  nat  -A  PREROUTING  -i  ethO  -j  DNAT  -to  192.1 68.1 .10 
A.2.4.4.  SJPhone  Installation  and  Configuration 
A.2.4.4. 1 .  Client  A  and  Client  B 

A.2.4.4. 1.1.  Download  the  Windows  version  of  SJPhone  v.160 
from  SJLabs 

A.2.4.4. 1.2.  Install  SJPhone  v.160 

A.2.4.4. 1.3.  Launch  SJPhone 

A.2.4.4. 1 .4.  Right-click  on  SJPhone 

A.2.4.4. 1.5.  Go  to  Services 

A.2.4.4. 1.6.  Select  PC-to-PC  (SIP) 

A.2.4.5.  Ethereal  Installation  and  Configuration 
A.2.4.5.1.  Client  A  and  Client  B 

A.2.4.5. 1 . 1 .  Download  the  latest  Windows  version  of  Ethereal 

A.2.4.5. 1.2.  Install  Ethereal 

A.2.4.5. 2.  NAT 

A.2.4.5. 2. 1 .  Install  Ethereal  if  it  is  not  already  installed: 

A.2.4.5. 2. 1.1.  Go  to  the  Desktop  menu 
A.2.4.5.2.1.2.  Go  to  System  Settings 
A.2.4.5.2.1.3.  Go  to  Add/Remove  Applications 
A.2.4.5. 2. 1.4.  Click  on  Details  under  System  Tools 
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A.2.4.5.2.1.5.  Find  and  then  check  ethereal-gnome 
A.2.4.5.2.1.6.  Click  on  Close 
A.2.4.5.2.1.7.  Click  on  Update 

A.2.4.5.2.1.8.  Put  in  the  correct  Fedora  Core  4  CDs  when 
prompted 

A. 3. Preparation  and  Testing 

A. 3. 1 .  Adjust  volume  on  both  clients  accordingly 
A. 3. 2.  Plug  microphones  into  both  clients 
A. 3. 3.  On  client  A, 


A. 3. 3.1. 

Launch  Ethereal 

A. 3. 3.2. 

Go  to  the  Capture  menu 

A.3.3.3. 

Go  to  Interfaces 

A. 3. 3.4. 

Click  on  Capture  192.168.0.10 

ABA.  On  client  B, 

A. 3. 4.1. 

Launch  Ethereal 

A. 3. 4.2. 

Go  to  the  Capture  menu 

A.3.4.3. 

Go  to  Interfaces 

A. 3. 4.4. 

Click  on  Capture  1 92. 1 68. 1 . 1 0 

A.3.5.  On  NAT, 

A. 3. 5.1. 

Launch  one  instance  of  Ethereal 

A. 3. 5.2. 

Go  to  the  Capture  menu 

A.3.5. 3. 

Go  to  Interfaces 

A. 3. 5.4. 

Click  on  Capture  EthO 

A.3.5. 5. 

Launch  another  instance  of  Ethereal 

A.3.5. 6. 

Go  to  the  Capture  menu 

A.3.5. 7. 

Go  to  Interfaces 

A.3.5. 8. 

Click  on  Capture  Eth  1 

A. 3. 6.  On  Client  B, 

A. 3. 6.1.  Call  A  by  dialing  192.168.0.10  in  SJPhone 

A. 3. 7.  On  Client  A, 

A. 3. 7. 1 .  Select  Accept  in  the  pop-up  dialog  box  when  SJPhone  rings 
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A. 3. 8.  Clients  A  and  B  may  engage  in  a  VoIP  conversation  at  this  point 
A. 3. 9.  Click  on  the  Hang-Up  bottom  on  either  SJPhone  to  tenninate  the  call 
when  finished 

A. 3. 10. On  Client  A,  Client  B,  and  NAT, 

A. 3. 10. 1 .  Stop  packet  captures  by  selecting  Stop  on  Ethereal 
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A.4.  Packet  Captures 
A.4.1.  Client  A 

Figure  19  is  a  snapshot  of  the  packets  captured  on  Client  A. 
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Figure  19.  Test  2:  Packet  Capture  on  Client  A  (without  firewall) 
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A.4.2.  Client  B 

Figure  20  is  a  snapshot  of  the  packets  captured  on  Client  B. 
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Figure  20.  Test  2:  Packet  Capture  on  Client  B  (without  firewall) 
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A.4.3.  NATethO 

Figure  2 1  is  a  snapshot  of  the  packets  captured  on  the  first  interface  (ethO)  of 
the  NAT  device. 
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Figure  2 1 .  Test  2:  Packet  Capture  on  ethO  of  NAT  (without  firewall) 
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AAA.  NATethl 

Figure  22  is  a  snapshot  of  the  packets  captured  on  the  second  interface  (ethl) 
of  the  NAT  device. 


Figure  22.  Test  2:  Packet  Capture  on  ethl  of  NAT  (without  firewall) 
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A.4.5.  Analysis 

Since  all  packets  exchanged  between  Clients  A  and  B  are  processed  by  the  NAT 
rules,  understanding  those  rules  is  essential  when  analyzing  the  traffic  flow  captured  by 
Ethereal.  The  SNAT  rule  “iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  192.168.0.1” 
instructed  the  NAT  device  to  modify  the  source  IP  address  of  all  outgoing  packets  to 
192.168.0.1  before  routing  them.  Thus,  all  the  packets  received  by  Client  A  appeared  to 
come  from  the  NAT  device  (see  packet  capture  for  Client  A).  The  DNAT  rule  “iptables  -t 
nat  -A  PREROUTING  -i  ethO  -j  DNAT  -to  192.168.1.10”  instructed  the  NAT  device  to  change 
the  destination  IP  address  of  all  incoming  packets  to  192.168.1.10  before  routing  those 
packets.  This  operation  allowed  packets  sent  to  the  NAT  to  be  routed  to  Client  B. 

The  process  of  establishing  a  connection  between  Clients  A  and  B  in  this  test  was 
very  similar  to  the  one  described  in  Appendix  B.  First,  Client  B  sent  out  an  “INVITE” 
message  from  192.168.1.10:5060  to  192.168.0.10:5060  on  Client  A  (red  outline  in  Figure 
19).  The  “INVITE”  message  had  embedded  SDP  information  to  inform  Client  A  that 
Client  B  will  send  and  receive  RTP  voice  packets  at  192.168.1.10  on  port  49154  (green 
outline  in  Figure  19).  Client  A  acknowledged  the  invitation  by  sending  Client  A  an  “200 
OK”  message  with  embedded  SDP  infonnation  indicating  that  it  will  send  and  receive 
RTP  packets  at  192.168.0.10  on  port  49152  (orange  outline  in  Figure  20). 

Subsequent  voice  communication  between  the  two  clients  was  sent  to  the  IP 
addresses  and  ports  specified  in  SDP.  In  other  words,  Client  B  sent  RTP  packets  directly 
to  Client  A  at  192.168.0.10  and  Client  A  sent  RTP  packets  directly  to  Client  B  at 
192.168.1.10  (blue  outline  in  Figure  19).  The  former  was  legitimate  because  Client  A 
was  publicly  reachable.  But  the  latter  was  only  possible  in  our  setup  since  neither  Client 
A  nor  the  NAT  device  was  configured  to  drop  packets  destined  for  private  IP  addresses. 
In  this  case,  the  NAT  device  simply  forwarded  the  RTP  packets  to  client  B  (see  Figures 
21  and  22).  To  simulate  a  more  realistic  network  configuration,  a  firewall  was  needed  to 
drop  packets  sent  by  Client  A  and  destined  for  Client  B. 
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B.  With  Firewall 
B.  1 .  Network  Topology 

Refer  to  Figure  7  and  Figure  8  for  the  physical  and  logical  network  topology. 

B.2.  Preparation  and  Testing  (in  addition  to  all  steps  described  in  Section  A) 

B.2.1.  On  Client  A, 

B.2. 1 . 1 .  Download  the  ZoneAlarm  from  Zone  Labs 
B.2. 1 .2.  Install  ZoneAlarm 

B.2. 1 .3.  When  ZoneAlarm  is  being  run  for  the  first  time,  it  will  ask  the  user 
to  choose  between  Basic  ZoneAlarm  or  the  trial  version  of  ZoneAlarm 
Pro,  select  the  trial  version  of  ZoneAlarm 
B.2. 1 .4.  When  asked  to  select  a  security  level  for  the  detected  network, 
select  Allow  into  Trusted  Zone 
B.2. 1 .5.  Configure  firewall  rule  in  ZoneAlarm: 

B.2.1. 5.1.  Go  to  Firewall  menu  on  the  left  panel 
B.2. 1.5.2.  Click  on  the  Expert  tab 
B.2. 1.5.3.  Click  on  Add 

B.2. 1 .5.4.  Type  in  a  name  for  the  firewall  rule  in  the  Name  textbox 
B.2. 1.5.5.  Under  Action,  select  Block 
B.2. 1.5.6.  Under  Destination, 


B.2.1. 5. 6.1. 

Select  Modify 

B.2.1. 5. 6.2. 

Select  Add  Location 

B.2.1. 5. 6. 3. 

Select  IP  Address 

B.2.1. 5. 6.4. 

Type  in  a  description  in  the  Description  textbox 

B.2.1. 5. 6. 5. 

Type  192.168.1.10  in  the  IP  Address  textbox 

B.2.1. 5. 6. 6. 

Click  OK 

B.2.1. 5. 6. 7. 

Click  OK 

B.2.1. 5. 6. 8. 

Click  Apply 

B.2.2.  Run  test  as  described  in  Section  A 
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B. 3.  Packet  Captures 
B.3.1.  Client  A 


Figure  23  is  a  snapshot  of  the  packets  captured  on  Client  A. 
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Figure  23.  Test  2:  Packet  Capture  on  Client  A  (with  firewall) 
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B.3.2.  Client  B 


Figure  24  is  a  snapshot  of  the  packets  captured  on  Client  B. 
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Figure  24.  Test  2:  Packet  Capture  on  Client  B  (with  firewall) 


65 


B.3.3.  NATethO 

Figure  25  is  a  snapshot  of  the  packets  captured  on  the  first  interface  (ethO)  of 
the  NAT  device. 
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Figure  25.  Test  2:  Packet  Capture  on  ethO  of  NAT  (with  firewall) 
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B.3.4.  NATethl 

Figure  26  is  a  snapshot  of  the  packets  captured  on  the  second  interface  (ethl) 
of  the  NAT  device. 
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•  -nm  :>:!  r  »'•*.  82!  :■/•*■ 

.  R^nw  II.  5 rc:  192.168.1.10  (00:0f:lfdl:d7:d),  05t:  192.168.1.1  (00:01:02:89:9?:!0) 
I  internet  Protocol,  Src:  192.168.1.10  (192.168.1.10).  On:  192.168.0.10  (192.168.0.10) 

!  iMr  04149781  Protocol.  Src  Port:  50«  (1060),  Oit  Port:  1060  (5060; 

S3/C6  por.:  K«0  (!060) 

Oetlnatlai  port:  6C60  (8060) 

Length:  771 

CfWsw:  i'isa  [corr«t] 
r  seoslon  initiation  protocol 
t  Pe8WSM.il*:  inrtTE  slp:192.168.0.10  SIP/3.0 

« no*  H*4i*r 
-  *«iigi  My 

=  Session  tescrlptlon  Protocol 

iessltn  Description  Protocol  version  (»):  0 
.  ow/crtltor,  session  ID  (0):  -  3334371610  33X  371610  1»  l«  192.168.U0 
Session  (8*  (s):  s:pxr» 

>  Conrectlcn  inforeetlon  (c):  I«  IP4  192.168.1.10 

■  tie*  ascription,  tctlv*  tie*  (t):  1 0 

>  session  Jittrlsute  (*):  «lrectlcr:*ctiv* 

s  8*01 1  Description,  nwe  »"C  tOJreis  («):  audio  49212  «1W  3  97  98  8  0  101 
1 8*dli  Pnrltwt*  (t):  rtjwp:!  G9V9M0 

>  8*01*  ettrlbPte  (4):  rtp«p:97  liec/8000 
*  8*dl4  attribute  (*):  rtpwp:98 1L8C/8000 
t  Kedls  attribute  (4):  f»tp:98  «<*■:: 

■  8*01 4  Pnrltwt*  (4):  rtpiip:3  WsOO: 


itttus:  100  Trying 
Stetus:  180  Pinging 

status:  200  oe.  Kith  session  description 
legjKt:  Kt  s1p:192.1S8.0.10:50« 

Plyloed  tyPHSt  06.10,  SSBC-37W025.  S*4>!926,  TM,  airt 
HyloaS  typMSt  06.10.  SSeC.37954025.  S*»!9!7.  TlwlSC 
P|yl04d  tyt*-13<  06.10,  SaMlJWM,  ieg.268M.  Ttae.320 
P4ylO40  typ*8»  06.10.  S!K*3795S02!.  Seo-5928.  Tlw.320 
Plyloed  type*?  06.10.  55PC.11791073!,  seg.2689:.  Tlae-tK 
PlyloaS  tyPHl?  06.10.  SSWC-J7V54025.  Seg-1929,  71*410 
PlylOM  typWSt  06.10.  SSeC-117940731.  Seg.21891.  Tl»«0 
Ply  lad  Type-13*  06.10.  5S»M 795402!.  Sco-!930.  Thecae 
Plyl04d  tyw-191  06.10.  S9C.U7940731,  Seg.24892,  71*809 
*iylao  Type-13*  06.10.  SSK-3793402!.  seg.1931.  71*800 
P4yl081  tyP4-Ht  06.10.  S9C-1179407]!,  SW26891.  7ti*-96C 
Plyloed  type-13*  06.10.  S9C.3T954021.  Se>!932,  Tl*96C 
Plyloed  type— 3SP*  06.10.  S3C-11791073!,  5*g-26891,  71*1120 
payload  typHW  06.10.  SSWC-37954025.  S*0-!933,  71*1120 
Payload  typ e-3<  06.10.  i3C.ll 79(0731,  seg.2689!.  Tlae.1280 
Payload  typ«<3  06.15,  S3C*3795(025.  S40.19S4,  71*1280 
Payload  typeaat  06.10.  S9C.1179I073!.  Seg.2689!,  Ttee-luo 
p(ylac  type— ISP*  06.10.  S3C.1795402!,  Se»*59}5.  T1*1440 
Payload  typW9t  06.10.  S8M1794073!,  Seg.26897.  11*1600 
Payload  typhOt  06.10.  S3C.37954021,  Se».S934.  Tlee-1400 
Payload  typ4<9t  06.10,  S8C.U794073S,  ag.26898,  Tlee-1740 
payload  typWBt  06.10.  S3C.37954021.  S*O.S9!7.  71*1760 
oiuloM  ronwxi  ot.io.  nar.ii7eao7ii.  t*n.w.  ri*ta70 
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Figure  26.  Test  2:  Packet  Capture  on  ethl  of  NAT  (with  firewall) 
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B.3.5.  Analysis 

The  signaling  part  of  the  call  was  processed  as  usual  with  the  exchanges  of 
“INVITE”  (red  outline  in  Figure  23)  and  “200  OK”  (orange  outline  in  Figure  24) 
messages  between  the  two  clients.  Client  B  still  told  Client  A  to  send  RTP  media  packets 
to  its  private  IP  address  or  192.168.1.10  (green  outline  in  Figure  23).  However,  Client  A 
can  no  longer  send  RTP  packets  directly  to  Client  B  at  its  private  address  because 
ZoneAlarm  was  configured  to  block  those  packets.  The  ZoneAlarm  log  files  were 
examined  to  confirm  that  packets  destined  for  192.168.1.10  were,  in  fact,  dropped.  The 
packet  captures  on  Client  A  indicate  that  when  Client  A  failed  to  send  RTP  packets  to  the 
IP  address  of  Client  B,  it  tried  to  send  subsequent  RTP  packets  to  the  IP  address  from 
which  it  received  RTP  packets  (due  to  the  SNAT  rule).  In  this  case,  Client  A  sent  the 
RTP  packets  to  the  public  IP  address  NAT  or  192.168.0.1  (blue  outline  in  Figure  23). 
When  NAT  received  the  packets,  it  modified  the  destination  address  in  the  packet  header 
according  to  the  configured  DNAT  rule.  In  other  words,  NAT  changed  the  destination 
address  from  its  own  public  IP  address  (192.168.0.1)  to  the  private  IP  address  of  Client  B 
(192.168.1.10)  before  forwarding  the  packets  (dark  red  outline  in  Figure  24).  Figures  25 
and  26  confirm  that  DNAT  and  SNAT  were  done  correctly. 
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APPENDIX  D.  TEST  3:  DOUBLE  NAT  VOIP  DEMONSTRATION 

USING  SJPHONE 


The  instructions  contained  in  this  appendix  describe  how  to  setup  and 
demonstrate  a  SIP-based  VoIP  communication  between  two  SIP-enabled  clients  via  two 
Network  Address  Translation  (NAT)  devices.  In  this  setup,  Client  B  is  located  behind 
two  NATs.  Each  NAT  is  configured  to  act  as  a  router  and  modifies  the  destination  or 
source  IP  address  of  all  packets  that  traverses  it.  Packet  captures  from  both  clients  are 
included  at  the  end  of  this  appendix  along  with  an  analysis. 

A.  Network  Topology 

Refer  to  Figures  9  and  Figure  10  for  the  physical  and  logical  network  topology. 

B.  Equipment  Requirements 
B .  1 .  Clients  A  and  B 

B .  1 . 1 .  Windows  XP  Operating  System 
B.1.2.  Soundcard 
B.1.3.  SJPhone  v.  1 .60 
B.1.4.  Ethereal 

B .  1 . 5 .  ZoneAlann  (Client  A  only) 

B.2.  NAT  1  and  NAT  2 

B.2. 1 .  Linux  Operating  System  (Fedora  Core  4) 

B.2.2.  netfilter  and  iptables 

B.2.3.  Ethereal 

B.2.4.  Two  network  cards 

B. 3.  Additional  equipment 

B.3. 1 .  Cross-over  cables  to  implement  the  network  architecture  illustrated  in 
Figure  9 

B.3.2.  Microphones  as  audio  input  devices  for  clients  A  and  B 

C.  Installation  and  Configuration 

C. l.  Client  A 

IP  Address:  192.168.0.10 
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Subnet  Mask:  255.255.255.0 
Default  Gateway:  192.168.0.1 
C.2.  Client  B 

IP  Address:  192.168.2.10 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  192.168.2.1 
C.3.NAT  1 

C.3.1.  Configure  ethO  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethO 
DEVICE=ethO 
BOOTPROTO=NONE 
IPADDR=192. 168.0.1 
NETMASK=255. 255. 255.0 
C.3.2.  Activate  ethO  by  running: 
ifup  ethO 

C.3.3.  Configure  ethl  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethl : 
DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.1 .1 
NETMASK=255. 255. 255.0 
C.3.4.  Activate  ethl  by  running: 
ifup  ethl 

C.3.5.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 
C.3.6.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
iptables  -t  nat  -F 

C.3.7.  Configure  NAT  rules  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  192.168.0.1 
iptables  -t  nat  -A  PREROUTING  -i  ethO  -j  DNAT  -to  192.168.1.2 

C.4.NAT  2 

C.4.1.  Configure  ethO  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethO 
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DEVICE=ethO 
BOOTPROTO=NONE 
IPADDR=192.168.1 .2 
NETMASK=255. 255. 255.0 
GATE  WAY=  192. 168. 1.1 
C.4.2.  Activate  ethO  by  running: 
ifup  ethO 

C.4.3.  Configure  ethl  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethl : 
DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.2.1 
NETMASK=255. 255. 255.0 
C.4.4.  Activate  ethl  by  running: 
ifup  ethl 

C.4.5.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 

C.4.6.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
iptables  -t  nat  -F 

C.4.7.  Configure  NAT  rules  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  192.168.1.2 
iptables  -t  nat  -A  PREROUTING  -i  ethO  -j  DNAT  -to  192.168.2.10 
C.5.  SJPhone  Installation  and  Configuration 
C.5.1.  Clients  A  and  B 

C.5. 1 . 1 .  Download  the  Windows  version  of  SJPhone  v.  1 .60  from  SJ  Fabs 

C .  5 . 1 .2 .  Install  SJPhone  v.  1 . 60 

C.5.1.3.  Faunch  SJPhone 

C.5.1.4.  Right-click  on  SJPhone 

C.5.1.5.  Right-click 

C.5.1.6.  Go  to  Services 

C.5.1.7.  Select  PC-to-PC  (SIP) 
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C.6.  Ethereal  Installation  and  Configuration 
C.6. 1 .  Clients  A  and  B 

C.6.1.1.  Download  the  Windows  version  of  Ethereal  v.0.10.12 
C.6. 1 .2.  Install  Ethereal  v.0. 10. 12  by  following  on-screen  instructions 
C.6.2.  NAT  1  and  NAT  2 

C.6.2. 1.1.  Install  Ethereal  if  it  is  not  already  installed 


C.6.2. 1.1.1. 

Go  to  the  Desktop  menu 

C.6.2. 1.1.2. 

Go  to  System  Settings 

C.6.2. 1.1.3. 

Go  to  Add/Remove  Applications 

C.6.2. 1.1.4. 

Click  on  Details  under  System  Tools 

C.6.2. 1.1.5. 

Find  and  then  check  ethereal-gnome 

C.6.2. 1.1.6. 

Click  on  Close 

C.6.2. 1.1.7. 

Click  on  Update 

C.6.2. 1.1.8. 

Put  in  the  correct  Fedora  Core  4  CDs  when 

prompted 

C.7.  ZoneAlann  Installation  and  Configuration 
C.7.1.  On  client  A, 

C.7. 1 . 1 .  Download  the  free  ZoneAlann  from  Zone  Labs 
C.7. 1 .2.  Install  ZoneAlann  by  following  on-screen  instructions 
C.7. 1 .3.  When  ZoneAlann  is  being  run  for  the  first  time,  it  will  ask  the  user 
to  choose  between  Basic  ZoneAlann  or  trial  version  of  ZoneAlann  Pro, 
select  the  trial  version  of  ZoneAlann 
C.7. 1 .4.  Answer  on-screen  questions 

C.7. 1 .5.  When  asked  to  select  a  security  level  for  the  detected  network, 
select  Allow  into  Trusted  Zone 
C.7. 1 .6.  Configure  firewall  rule  in  ZoneAlann: 

C.7.1. 6.1.  Go  to  Firewall  menu  on  the  left  panel 
C.7. 1 .6.2.  Click  on  the  Expert  tab 
C.7. 1.6.3.  Click  on  Add 

C.7. 1 .6.4.  Type  in  a  name  for  the  firewall  rule  in  the  Name  textbox 
C. 7. 1.6.5.  Under  Action,  select  Block 
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C.7. 1.6.6.  Under  Destination, 


C. 7. 1.6. 6.1. 

Select  Modify 

C. 7. 1.6. 6.2. 

Select  Add  Location 

C.7.1.6.6.3. 

Select  IP  Address 

C. 7. 1.6. 6.4. 

Type  in  a  description  in  the  Description  textbox 

C.7.1.6.6.5. 

Type  192.168.2.10  in  the  IP  Address  textbox 

C.7.1.6.6.6. 

Click  OK 

C.7.1.6.6.7. 

Click  OK 

C.7.1.6.6.8. 

Click  Apply 

D.  Preparation  and  Testing 

D.  1 .  Adjust  volume  on  both  clients  accordingly 
D.2.  Plug  microphones  into  both  clients 
D.3.  On  Client  A, 

D.3. 1 .  Launch  Ethereal 
D.3.2.  Go  to  the  Capture  menu 
D.3.3.  Go  to  Interfaces 
D.3.4.  Click  on  Capture  192.168.0.10 
D.4.  On  Client  B, 

D.4. 1 .  Launch  Ethereal 
D.4.2.  Go  to  the  Capture  menu 
0.4.3.  Go  to  Interfaces 
D.4.4.  Click  on  Capture  192.168.2.10 
D.5.0nNAT  1  (Ethereal  not  installed), 

D .5 . 1 .  Launch  one  tenninal  and  run: 
tcpdump  -n  -i  ethO 

D.5.2.  Launch  another  terminal  and  run: 
tcpdump  -n  -i  ethl 
D.6.0n  NAT  2, 

D.6. 1 .  Launch  one  instance  of  Ethereal 
D.6.1.1.  Go  to  the  Capture  menu 

D.6.1.2.  Go  to  Interfaces 
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D.6.1.3.  Click  on  Capture  EthO 
D.6.2.  Launch  another  instance  of  Ethereal 
D.6.2.1.  Go  to  the  Capture  menu 

D.6.2.2.  Go  to  Interfaces 

D.6.2.3.  Click  on  Capture  Eth  1 
D.7.  On  Client  B, 

D.7.1.  Call  A  by  dialing  192.168.0.10  in  SJPhone 
D.8.  On  Client  A, 

D.8. 1 .  Select  Accept  in  the  pop-up  dialog  box  when  SJPhone  rings 
D.8.2.  Clients  A  and  B  may  engage  in  a  VoIP  conversation  at  this  point. 

D.8.3.  Click  on  the  Hang-Up  bottom  on  either  SJPhone  to  terminate  call  when 
finished 

D.8.4.  On  NAT  1, 

D.8.4. 1 .  Stop  tcpdump  packet  captures  by  pressing  Control-C  on  the 
tenninals 

D.8.5.  On  Client  A,  Client  B  and  NAT  2, 

D.8.5. 1 .  Stop  packet  captures  by  selecting  Stop  on  Ethereal 
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E.  Packet  Captures 
E.  1 .  Client  A 


The  following  is  a  snapshot  of  the  packets  captured  on  Client  A. 


■\ 


red 


blue 


green 


Figure  27.  Test  3:  Packet  Capture  on  Client  A 
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E.2.  Client  B 


The  following  is  a  snapshot  of  the  packets  captured  on  Client  B. 


y 


orange 


purple 


Figure  28.  Test  3:  Packet  Capture  on  Client  B 
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E.3.  NAT  1  EthO 

The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface  (ethO)  of 
NAT  1. 


File  Edit  View  Insert  Format  Help 


/Microphone  [pTools|  ^Handwriting  ^Drawing Pad  I  (’I  *  JlJxj 


DltflBlllBlftl 


16:49:34.013015 

IP  192.168.0.10.5003  >  192.168.0.255.5003:  UDP,  length  125 

1 

16:50:10.246156 

IP  192.168.0.1.5060  >  192.168.0.10.5060:  DDP,  length  763 

16:50:10.281597 

arp  who-has  192.168.0,1  tell  192.168.0.10 

16:50:10.281648 

arp  reply  192.168.0.1  is-at  00:4c:69:6e:75:79 

16:50:10.281797 

IP 

192.168.0.10.5060  >  192.168.0.1.5060:  UDP,  length  377 

16:50:10.297025 

IP 

192. 168,0. 10. netbios-ns  >  192. 168.0. 255. netbios-ns:  SBT  OOP  PACKET(137) :  QUERY; 

REQUEST; 

BROADCAST 

16:50:10.557888 

IP 

192.168.0.10.5060  >  192.168.0.1.5060:  DDP,  length  412 

16:50:11.041095 

IP 

192. 168. 0.10. netbios-ns  >  192. 168. 0.255. netbios-ns:  SBT  UDP  PACKET(137) :  QUERY; 

REQUEST; 

BROADCAST 

16:50:11.790633 

IP 

192. 168. 0.10. netbios-ns  >  192. 168. 0.255. netbios-ns:  SBT  UDP  PACKE1(137):  QUERY; 

REQUEST; 

BROADCAST 

16:50:12.261940 

IP 

192.168.0.10.5060  >  192.168.0.1.5060:  UDP,  length  658 

16:50:12.271112 

IP 

192.168.0.1.5060  >  192.168.0.10.5060:  UDP,  length  376 

16:50:12.276174 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.289297 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.296086 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.308339 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.316182 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.328013 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.335969 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45| 

16:50:12.348013 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.356561 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.367951 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.376034 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.388070 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.395956 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.408445 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.415943 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.428041 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.436064 

IP 

192.168.0.1.49204  >  192. 16B. 0.10.49182:  UDP,  length 

45 

16:50:12.448135 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.455952 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.467980 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.475940 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.487996 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.495921 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12,508149 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.516253 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.528281 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.535923 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.543988 

IP 

192. 168. 0.10. netbios-ns  >  192. 168. 0.255. netbios-ns: 

UBI  UDP  PACKET (137) :  QUERY; 

REQUEST; 

BROADCAST 

16:50:12.548478 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.555954 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.567954 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.575939 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.588117 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.595921 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.607974 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.615900 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.627981 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.635963 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.645900 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.647982 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

16:50:12.665951 

IP 

192.168.0.1.49204  >  192.168.0.10.49182:  UDP,  length 

45 

16:50:12.668234 

IP 

192.168.0.10.49182  >  192.168.0.1.49204:  UDP,  length 

45 

d 

ForHet,  pressFl 


rr 


Figure  29.  Test  3:  Packet  Capture  on  ethO  of  NAT  1 
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E.4.  NAT  1  Ethl 

The  following  is  a  snapshot  of  the  packets  captured  on  the  second  interface  (ethl) 
of  NAT  1. 


1 8-25_NAT  1_2NAT_ETH1_B_CALL_A  ■  WordPad 

/Microphone  lilTools  /.Handling  fff Drawing  Pad  Uj  ; 

file  Edit  View  Insert  Format  Help 

DitflBl  ilBl  «l  MiH%| 

16:50:10.246093  IP  192.168.1.2.5060  >  192.168.0.10.5060 

UDP,  length  763  - 

16:50:10.281844  IP  192.168.0.10.5060  >  192.168.1.2.5060 

UDP,  length  377 

16:50:10.557947  IP  192.168.0.10.5060  >  192.168.1.2.5060 

OOP,  length  412 

16:50:12.262002  IP  192.168.0.10.5060  >  192.168.1.2.5060 

UDP,  length  658 

16:50:12.271082  IP  192.168.1.2.5060  >  192.168.0.10.5060 

UDP,  length  376 

16:50:12.276141  IP  192,168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.289314  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.296071  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.308405  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.316163  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.328032  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.335953  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.348068  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.356540  IP  192.168.1.2.49204  >  192.168.0,10.49182 

UDP,  length  45 

16:50:12.367969  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.376018  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.388086  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.395905  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.408465  IP  192.168.0.10.49182  >  192. 16B. 1.2. 49204 

UDP,  length  45 

16:50:12.415925  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45| 

16:50:12. 42805B  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.436012  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.448155  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.455931  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.468032  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.475922  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.488052  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.495901  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.508168  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.516237  IP  192.168.1.2.49204  >  192.168.0,10.49182 

UDP,  length  45 

16:50:12.528349  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.535904  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.548496  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.555936  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.567970  IP  192,168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.575889  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.588138  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.595904  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.607989  IP  192.168.0.10.45182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.615885  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.628035  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.635943  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.645882  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.647998  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.665900  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.668255  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.685878  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.688041  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.705932  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.707958  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.725904  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45 

16:50:12.728001  IP  192.168.0.10.49182  >  192.168.1.2.49204 

UDP,  length  45 

16:50:12.745909  IP  192.168.1.2.49204  >  192.168.0.10.49182 

UDP,  length  45  ▼] 

For  Help,  press  FI 

Figure  30.  Test  3:  Packet  Capture  on  ethl  of  NAT  1 
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E.5.  NAT  2  EthO 

The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface  (ethO)  of 
NAT  2. 


Figure  3 1 .  Test  3:  Packet  Capture  on  ethO  of  NAT  2 
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E.6.  NAT  2  Ethl 

The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface  (ethO)  of 
NAT  2. 


Figure  32.  Test  3:  Packet  Capture  on  ethl  of  NAT  2 
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E.7.  Analysis 

This  demonstration  was  very  similar  to  the  one  described  in  Appendix  C.  It 
differed  in  that  now  Client  B  is  located  behind  two  NAT  devices  instead  of  one.  In  other 
words,  two  layers  of  network  address  translation  occurred  before  any  packet  can  be 
moved  between  Client  A  and  Client  B. 

The  “INVITE”  message  (red  outline  in  Figure  27)  indicated  that  Client  B  will  be 
sending  and  receiving  RTP  packets  at  192.168.2.10  on  port  49204  (purple  outline  in 
Figure  28).  Client  A  acknowledged  the  invitation  by  sending  a  “200  OK”  message  to 
Client  B  with  embedded  SDP  information  indicating  that  it  would  send  and  receive  RTP 
packets  at  192.168.2.10  on  port  49182  (green  outline  in  Figure  27).  Figures  27  and  29 
show  that  Client  A  sends  and  receives  RTP  packet  directly  to/from  the  public  IP  address 
of  NAT  1 .  As  explained  in  Appendix  C,  S  JPhone  will  first  attempt  to  send  RTP  media 
packets  to  the  IP  address  indicated  in  the  SDP  message  (or  the  private  IP  address  of 
Client  B).  Since  the  firewall  installed  on  Client  A  was  configured  to  drop  packets 
destined  to  for  Client  B,  none  of  the  packets  sent  out  by  Client  A  ever  reached  Client  B. 
Therefore,  Client  A  resorted  to  sending  subsequent  RTP  packets  to  the  IP  address  from 
which  it  received  Client  B’s  RTP  media  packets  (blue  outline  in  Figure  27).  In  this  case, 
the  packets  were  sent  to  the  public  IP  address  of  the  NAT  1  device  (192.168.0.1). 
Figures  29  and  30  confirmed  that  the  configured  NAT  operated  correctly. 
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APPENDIX  E.  TEST  4:  EXTENDED  DOUBLE  NAT  VOIP 
DEMONSTRATION  USING  SJPHONE 


The  instructions  contained  in  this  appendix  describe  how  to  setup  and 
demonstrate  a  SIP-based  VoIP  communication  between  two  SIP-enabled  clients  via 
Network  Address  Translation  (NAT)  devices.  In  this  setup,  NAT  1  is  no  longer 
configured  with  a  DNAT  rule  to  rewrite  the  destination  IP  address  of  the  packets  that 
traverse  it.  Therefore,  NAT  1  only  perfonns  SNAT.  NAT  2  and  NAT  3  are  each 
configured  with  both  SNAT  and  DNAT  rules.  The  demonstration  is  conducted  as 
follows:  Client  B  initiates  a  call  to  Client  A.  Then  Client  C  initiates  a  call  to  Client  A 
after  the  VoIP  session  between  Client  B  and  A  is  tenninated.  Packet  captures  from  all 
three  clients  and  the  NATs  are  included  at  the  end  of  this  appendix  along  with  an 
analysis. 


A.  Network  Topology 

Refer  to  Figure  13  and  Figure  14  for  the  physical  and  logical  network  topology. 

B.  Equipment  Requirements 
B.  1 .  Clients  A,  B  and  C 

B .  1 . 1 .  Windows  XP  Operating  System 
B.1.2.  Soundcard 
B.1.3.  SJPhone  v.  1 .60 
B.1.4.  Ethereal 

B.  1 .5.  ZoneAlann  (Client  A  only) 

B.2.  NAT  1,  NAT  2  and  NAT  3 

B.2. 1 .  Linux  Operating  System  (Fedora  Core  4) 

B.2.2.  netfilter  and  iptables 
B.2.3.  Ethereal 
B.2.4.  Two  network  cards 
B.3.  Additional  Equipment 

B.3. 1 .  Cross-over  cables  and  a  switch  or  hub  to  implement  the  network 
architecture  illustrated  in  Figure  13 
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B. 3.2.  Microphones  as  audio  input  devices  for  clients  A,  B,  and  C 
C.  Installation  and  Configuration 

C.l.  Client  A 

IP  Address:  192.168.0.10 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  192.168.0.1 
C.2.  Client  B 

IP  Address:  192.168.2.10 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  192.168.2.1 
C.3.  Client  C 

IP  Address:  192.168.3.10 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  192.168.3.1 
C.4.NAT  1 

C. 4. 1 .  Configure  ethO  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethO 

DEVICE=eth0 
BOOTPROTO=NONE 
IPADDR=192. 168.0.1 
NETMASK=255. 255. 255.0 
C.4.2.  Activate  ethO  by  running: 
ifup  ethO 

C.4.3.  Configure  ethl  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethl 
DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.1.1 
NETMASK=255. 255. 255.0 
C.4.4.  Activate  ethl  by  running: 
ifup  ethl 

C.4.5.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 
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C.4.6.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
iptables  -t  nat  -F 

C.4.7.  Configure  NAT  rule  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  192.168.0.1 

C.5.NAT  2 

C.5.1.  Configure  ethO  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethO 
DEVICE=ethO 
BOOTPROTO=NONE 
IPADDR=192.168.1 .2 
NETMASK=255. 255. 255.0 
GATE  WAY=  192. 168. 1.1 

C.5.2.  Activate  ethO  by  running: 

ifup  ethO 

C.5.3.  Configure  ethl  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethl 
DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.2.1 
NETMASK=255. 255. 255.0 

C.5.4.  Activate  ethl  by  running: 

ifup  ethl 

C.5.5.  Enable  IP  forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 

C.5.6.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
iptables  -t  nat  -F 

C.5.7.  Configure  NAT  rules  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  192.168.1.2 
iptables  -t  nat  -A  PREROUTING  -i  ethO  -j  DNAT  -to  192.168.2.10 

C.6.NAT  3 

C.6. 1 .  Configure  ethO  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethO 
DEVICE=ethO 
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BOOTPROTO=NONE 
IPADDR=192.168.1 .3 
NETMASK=255. 255. 255.0 
GATE  WAY=  192. 168. 1.1 

C.6.2.  Activate  ethO  by  running: 

ifup  ethO 

C.6.3.  Configure  ethl  by  editing  and  saving  /etc/sysconfig/network- 
scripts/ifcfg-ethl : 

DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.3.1 
NETMASK=255. 255. 255.0 
C.6.4.  Activate  ethl  by  running: 
ifup  ethl 

C.6.5.  Enable  IP  forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 
C.6.6.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
iptables  -t  nat  -F 

C.6.7.  Configure  NAT  rules  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  1 92. 1 68. 1 .3 
iptables  -t  nat  -A  PREROUTING  -iethO  -j  DNAT  -to  192.168.3.10 
C.7.  SJPhone  Installation  and  Configuration 
C.7. 1 .  Clients  A,  B,  and  C 

C.7. 1.1.  Download  the  Windows  version  of  SJPhone  v.  1 .60  from  SJ  Labs 
C.7. 1 .2.  Install  SJPhone  v.  1 .60 

C.7.1.3.  Launch  SJPhone 
C.7. 1.3.1.  On  SJPhone, 

C.7.1.3. 1.1.  Right-click 

C.7.1.3. 1.2.  Go  to  Services 

C.7.1.3. 1.3.  Select  PC-to-PC  (SIP) 
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C.8.  Ethereal  Installation  and  Configuration 
C.8. 1 .  Clients  A,  B,  and  C 

C.8.1.1.  Download  the  Windows  version  of  Ethereal  v.0.10.12 
C.8.1.2.  Install  Ethereal  v.0.10.12 
C.8.2.  NAT  2  and  3 

C.8.2. 1 .  Install  Ethereal  if  it  is  not  already  installed 

C.8.2. 1.1.  Go  to  the  Desktop  menu 
C.8.2. 1.2.  Go  to  System  Settings 
C.8.2. 1 .3.  Go  to  Add/Remove  Applications 
C.8.2. 1 .4.  Click  on  Details  under  System  T ools 
C.8.2. 1.5.  Find  and  then  check  ethereal-gnome 
C.8.2. 1 .6.  Click  on  Close 
C.8.2. 1.7.  Click  on  Update 

C.8.2. 1 .8.  Put  in  the  correct  Fedora  Core  4  CDs  when  prompted 
C.8.2. 1.9. 

C.9.  ZoneAlann  Installation  and  Configuration 
C.9.1.  On  client  A, 

C.9. 1 . 1 .  Download  the  free  ZoneAlann  from  Zone  Labs 

C.9. 1 .2.  Install  ZoneAlann  by  following  on-screen  instructions 
C.9. 1 .3.  When  ZoneAlann  is  being  run  for  the  first  time,  it  will  ask  the  user 
to  choose  between  Basic  ZoneAlann  or  trial  version  of  ZoneAlann  Pro, 
select  the  trial  version  of  ZoneAlann 
C.9. 1 .4.  Answer  on-screen  questions 

C.9. 1 .5.  When  asked  to  select  a  security  level  for  the  detected  network, 
select  Allow  into  Trusted  Zone 
C.9. 1 .6.  Configure  firewall  rule  in  ZoneAlann: 

C.9. 1.6.1.  Go  to  Firewall  menu  on  the  left  panel 
C.9. 1 .6.2.  Click  on  the  Expert  tab 
C.9. 1.6.3.  Click  on  Add 

C.9. 1 .6.4.  Type  in  a  name  for  the  firewall  rule  in  the  Name  textbox 
C. 9. 1.6.5.  Under  Action,  select  Block 
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C.9. 1.6.6.  Under  Destination, 


C. 9. 1.6. 6.1. 

Select  Modify 

C. 9. 1.6. 6.2. 

Select  Add  Location 

C.9.1.6.6.3. 

Select  IP  Address 

C. 9. 1.6. 6.4. 

Type  in  a  description  in  the  Description  textbox 

C.9.1.6.6.5. 

Type  192.168.2.10  in  the  IP  Address  textbox 

C.9.1.6.6.6. 

Click  OK 

C.9. 1 .6.7.  Repeat  steps  C.9. 1 .6. 1  to  C.9. 1 .6.6.6  to  create  a  rule  to  block 
192.168.3.10 
C. 9. 1.6.8.  Click  OK 
C.9. 1.6.9.  Click  Apply 
D.  Preparation  and  Testing 

D.  1 .  Adjust  volume  on  both  clients  accordingly 
D.2.  Plug  microphones  into  both  clients 
D.3.  On  Client  A, 

D.3. 1 .  Launch  Ethereal 
D.3.2.  Go  to  the  Capture  menu 
D.3.3.  Go  to  Interfaces 
D.3.4.  Click  on  Capture  192.168.0.10 
D.4.  On  Client  B, 

D.4. 1.  Launch  Ethereal 
D.4.2.  Go  to  the  Capture  menu 
0.4.3.  Go  to  Interfaces 
D.4.4.  Click  on  Capture  192.168.2.10 
D.5.0n  NAT  1, 

D.5 . 1 .  Launch  one  terminal  and  run: 

tcpdump  -n  -i  ethO 

D.5. 2.  Launch  another  terminal  and  run: 
tcpdump  -n  -i  ethl 
D.6.0n  NAT  2  and  NAT  3, 

D.6. 1 .  Launch  one  instance  of  Ethereal 
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D.6.1.1.  Go  to  the  Capture  menu 

D.6.1.2.  Go  to  Interfaces 

D.6.1.3.  Click  on  Capture  EthO 
D.6.2.  Launch  another  instance  of  Ethereal 
D.6.2.1.  Go  to  the  Capture  menu 

D.6.2.2.  Go  to  Interfaces 

D.6.2. 3.  Click  on  Capture  Eth  1 

D.7.  On  Client  B, 

D.7.1.  Call  A  by  dialing  192.168.0.10  in  SJPhone 
D.8.  On  Client  A, 

D.8. 1 .  Select  Accept  in  the  pop-up  dialog  box  when  SJPhone  rings 
D.8.2.  Clients  A  and  B  may  engage  in  a  VoIP  conversation  at  this  point. 

D.8.3.  Click  on  the  Hang-Up  bottom  on  either  SJPhone  to  terminate  call  when 
finished 
D.9.0n  Client  A, 

Stop  tcpdump  packet  captures  by  pressing  Control-C 
D.10.  On  Client  A,  Client  B,  NAT  1,  NAT  2  and  NAT  3, 

D.  10. 1 .  Stop  packet  captures  by  selecting  Stop  on  Ethereal 
D.10.2.  Stop  packet  captures  on  NAT  Box  1  by  pressing  Control-C 
D.10.3.  Repeat  steps  D.3  to  D.8  for  Clients  A,  Client  C  ,  NATs  1  and  NAT  3 
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E.  Packet  Captures 
E.  1 .  Client  B  Calls  A 
E.1.1.  Client  A 

The  following  is  a  snapshot  of  the  packets  captured  on  Client  A  when 
Client  B  calls  Client  A. 
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Figure  33.  Test  4:  Packet  Capture  on  Client  A  (Client  B  Calls  Client  A) 
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E.1.2.  Client  B 


The  following  is  a  snapshot  of  the  packets  captured  on  Client  B  when 
Client  B  calls  Client  A. 
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Figure  34.  Test  4:  Packet  Capture  on  Client  B  (Client  B  Calls  Client  A) 
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E.1.3.  NATlEthO 

The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface 
(ethO)  of  NAT  1  when  Client  B  calls  Client  A. 


For  H*  [less  FI 


Test  4:  Packet  Capture  on  ethO  of  NAT  1  (Client  B  Calls  Client  A) 
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E.1.4.  NATlEthl 


The  following  is  a  snapshot  of  the  packets  captured  on  the  second 
interface  (ethl)  of  NAT  1  when  Client  B  calls  Client  A. 


=0  -!J.JS5=: 

Figure  35.  Test  4:  Packet  Capture  on  ethl  of  NAT  1  (Client  B  Calls  Client  A) 
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E.1.5.  NAT  2  EthO 

The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface 
(ethO)  of  NAT  2  when  Client  B  calls  Client  A. 
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B  Media  Attribute  (a):  rtpmap:3  GSM/8000 
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Figure  36. 
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E.1.6.  NAT  2  Ethl 


The  following  is  a  snapshot  of  the  packets  captured  on  the  second 
interface  (ethl)  of  NAT  2  when  Client  B  calls  Client  A. 


Figure  37.  Test  4:  Packet  Capture  on  ethl  of  NAT  2  (Client  B  Calls  Client  A) 
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E.1.7.  Analysis 

As  soon  as  Client  B  dialed  the  IP  address  of  Client  A,  Client  B  sent  out  an 
“INVITE”  message  to  Client  A  (red  outline  in  Figure  33).  The  message  had  embedded 
SDP  information  to  inform  Client  A  that  Client  B  would  be  sending  and  receiving  RTP 
packets  at  192.168.2.10  on  port  49232  (purple  outline  in  Figure  34).  To  acknowledge  the 
invitation,  Client  A  sent  a  “200  OK”  packet  to  Client  B  with  embedded  SDP  information 
indicating  that  it  would  send  and  receive  RTP  packets  at  192.168.2.10  on  port  49204 
(green  outline  in  Figure  33).  The  packets  captured  on  Client  A  indicate  that  Client  A 
sent  and  received  RTP  packet  directly  to/from  the  public  IP  address  of  NAT  1.  As 
explained  in  Appendix  C,  SJPhone  will  first  attempt  to  send  RTP  media  packets  to  the  IP 
address  indicated  in  the  SDP  message  (or  the  private  IP  address  of  Client  B).  Since  the 
firewall  installed  on  Client  A  was  configured  to  drop  packets  destined  to  the  private  IP 
address  of  Client  B,  none  of  the  packets  sent  out  by  Client  A  could  reach  Client  B. 
Therefore,  Client  A  then  sent  subsequent  RTP  packets  to  the  IP  address  in  which  received 
the  RTP  media  packets  (blue  outline  in  Figure  34) 

The  packet  captures  indicate  that  the  first  RTP  packet  is  sent  by  Client  B  (black 
outline  in  Figure  33).  Even  though  NAT  1  was  not  explicitly  configured  to  rewrite  the 
destination  IP  address  of  incoming  packets  to  192.168.1.2  (public  IP  address  of  NAT  2), 
NAT  1  intelligently  does  this  on  its  own.  A  reasonable  explanation  for  this  behavior  is 
that  iptables  in  NAT  1  maintained  information  for  packets  that  are  initiated  from  the  local 
network  [19].  In  our  scenario,  the  first  RTP  packet  is  processed  according  to  the  SNAT 
rule  when  it  arrives  at  NAT  1.  At  the  same  time,  NAT  1  created  an  entry  in  its 
connection  tracking  table  to  store  essential  infonnation  (such  as  source  and  destination  IP 
addresses  and  ports)  that  would  allow  it  to  associate  incoming  packets  with  the  session 
between  Client  A  and  Client  B.  Packets  detennined  to  belong  to  a  certain  packet 
previously  received  from  NAT  2  (due  to  SNAT)  had  their  destination  IP  address  changed 
to  the  public  IP  address  of  NAT  2  (refer  to  Figures  35  through  38).  This  is  evident  from 
observing  the  packet  captures  on  ethl  of  NAT  2. 
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E.2.  Client  C  Calls  Client  A 
E.2.1.  Client  A 

The  following  is  a  snapshot  of  the  packets  captured  on  Client  A  when 
Client  C  calls  Client  A. 


Figure  38.  Test  4:  Packet  Capture  on  Client  A  (Client  C  Calls  Client  A) 
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E.2.2.  Client  C 


The  following  is  a  snapshot  of  the  packets  captured  on  Client  C  when 
Client  C  calls  Client  A. 


Figure  39.  Test  4:  Packet  Capture  on  Client  C  (Client  C  Calls  Client  A) 
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E.2.3.  NAT  1  EthO 

The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface 
(ethO)  of  NAT  1  when  Client  C  calls  Client  A. 


Re  Edit  few  Insert  Format  Help 

DM  ilfil  »l  NiM%I 

tcpdump :  verbose  output  suppressed,  use  -v  or  -w  for  full  protocol  decode 
listening  on  ethO,  link-type  EN10MB  (Ethernet) ,  capture  size  86  bytes 
15:12:05.363305  IP  192.168,0.10.5003  >  192.168.0.255.5003:  UDP,  length  125 
15:12:09.848537  arp  who-has  192.168.0.10  tell  192.168.0.1 
15:12:09.848653  arp  reply  192.168.0.10  is-at  00:0f: If : 19:27:36 
15:12:09.848666  IP  192.168.0.1.5060  >  192.168.0.10.5060:  UDP,  length  761 
15:12:09.915163  IP  192.168.0.10.5060  >  192.168.0.1.5060:  UDP,  length  375 

15:12:09.937317  IP  192. 168.0. 10. netbios-ns  >  192. 168.0. 255. netbios-ns:  NBT  ODP  PACKET(137) :  QUERY;  REQUEST;  BROADCAST 
15:12:10.169579  IP  192.168.0.10.5060  >  192.168.0.1.5060:  ODP,  length  410 

15:12:10.683671  IP  192. 168. 0.10. netbios-ns  >  192.168.0.255 .netbios-ns :  NBT  ODP  PACKET(137) :  QUERY;  REQUEST;  BROADCAST 
15:12:11.433633  IP  192. 168. 0.10. netbios-ns  >  192.168.0.255 .netbios-ns :  NBT  UDP  PACRET(137) :  QUERY;  REQUEST;  BROADCAST 
15:12:15.017096  IP  192.168.0.10.5060  >  192.168.0.1.5060:  UDP,  length  656 
15:12:15.022473  IP  192.168.0.1.5060  >  192.168.0.10.5060:  UDP,  length  374 

15:12:15.031145  IP  192. 168. 0.10. netbios-ns  >  192.168.0.255 .netbios-ns :  NBT  UDP  PACKET(137):  QUERY;  REQUEST;  BROADCAST 
15:12:15.039016  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 


UDP,  length  45 
UDP,  length  45 
UDP,  length  45 
UDP,  length  45 
UDP,  length  45 
UDP,  length  45 


UDP,  length  45 
UDP,  length  45 
UDP,  length  45 
UDP,  length  45 
UDP,  length  45 
UDP,  length  45 
UDP,  lenjh  45 
UDP,  length  45 


15:12:15.043942  IP  192.168.0.10.49212  >  192.168.0.1.49156: 

15:12:15.059084  IP  192.168.0.1.49156  >  192.168.0.10.49212: 

15:12:15.062793  IP  192.168.0.10.49212  >  192.168.0.1.49156: 

15:12:15.078938  IP  192.168.0.1.49156  >  192.168.0.10.49212: 

15:12:15.082769  IP  192.168.0.10.49212  >  192.168.0.1.49156: 

15:12:15.099013  IP  192.168.0.1.49156  >  192.168.0.10.49212: 

15:12:15.102766  IP  192.168,0.10.49212  >  192.168,0.1.49156:  UDP,  length  45 
15:12:15.118927  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.123153  IP  192.168.0.10.49212  >  192.168.0.1.49156:  UDP,  length  45 
15:12:15.139059  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.142788  IP  192.168.0.10.49212  >  192.168.0.1.49156: 

15:12:15.158931  IP  192.168.0.1.49156  >  192.168.0.10.49212: 

15:12:15.162873  IP  192.168.0.10.49212  >  192.168.0.1.49156: 

15:12:15.178973  IP  192.168.0.1.49156  >  192.168.0.10.49212: 

15:12:15.182766  IP  192.168.0.10.49212  >  192.168.0.1.49156: 

15:12:15.198986  IP  192.168.0.1.49156  >  192.168.0.10.49212: 

15:12:15.202767  IP  192.168.0.10.49212  >  192.168.0.1.49156: 

15:12:15.218950  IP  192.168.0.1.49156  >  192.168.0.10.49212: 

15:12:15.222769  IP  192.168.0.10.49212  >  192.168.0.1.49156:  UDP,  length  45 
15:12:15.239103  IP  192.168,0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.242836  IP  192.168,0.10.49212  >  192.168,0.1.49156:  UDP,  length  45 
15:12:15.258924  IP  192.168,0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.262800  IP  192.168.0.10.49212  >  192.168.0.1.49156:  UDP,  length  45 
15:12:15.278968  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.282766  IP  192.168.0.10.49212  >  192.168.0.1.49156:  UDP,  length  45 
15:12:15.298936  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.302774  IP  192.168.0.10.49212  >  192.168.0.1.49156:  UDP,  length  45 
15:12:15.318972  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.322765  IP  192.168.0.10.49212  >  192.168.0.1.49156:  UDP,  length  45 
15:12:15.338997  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.343141  IP  192.168.0.10.49212  >  192.168.0.1.49156:  UDP,  length  45 
15:12:15.358925  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.363191  IP  192.168.0.10.49212  >  192.168.0.1.49156:  UDP,  length  45 
15:12:15.379073  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.383038  IP  192.168.0.10.49212  >  192.168.0.1.49156:  UDP,  length  45 
15:12:15.398964  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 
15:12:15.402797  IP  192.168.0.10.49212  >  192.168.0.1.49156:  UDP,  length  45 
15:12:15.418980  IP  192.168.0.1.49156  >  192.168.0.10.49212:  UDP,  length  45 

For  Help,  press  FI 


i 

am 


Figure  40.  Test  4:  Packet  Capture  on  ethO  of  NAT  1  (Client  C  Calls  Client  A) 
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E.2.4.  NAT  1  Ethl 


The  following  is  a  snapshot  of  the  packets  captured  on  the  second 
interface  (ethl)  of  NAT  1  when  Client  C  calls  Client  A. 


For  Help,  press  FI 


Figure  41.  Test  4:  Packet  Capture  on  ethl  of  NAT  1  (Client  C  Calls  Client  A) 
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E.2.5.  NAT  3  EthO 


The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface 
(ethO)  of  NAT  3  when  Client  C  calls  Client  A. 


file:  t;/3  NATJB-26  (3  NATS  NAT  3  eM)  C  Call  A)'  |P:893D:  893M:0 


Figure  42.  Test  4:  Packet  Capture  on  ethO  of  NAT  3  (Client  C  Calls  Client  A) 
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E.2.6.  NAT  3  Ethl 


The  following  is  a  snapshot  of  the  packets  captured  on  the  second 
interface  (ethl)  of  NAT  3  when  Client  C  calls  Client  A. 


He  ■E/3  NAT/8-26  (!  NATS  NAT  3  dhl  C  M »)'  |P:®D;K*0 


Figure  43.  Test  4:  Packet  Capture  on  ethl  of  NAT  3  (Client  C  Calls  Client  A) 
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E.2.7.  Analysis 

The  sequences  of  packet  exchanges  between  Clients  A  and  C  are  similar  to 
that  of  Clients  A  and  B  described  in  the  previous  subsection.  See  Section  E.  1 .7  for 
explanation. 
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APPENDIX  F.  TEST  5:  EXTENDED  DOUBLE  NAT  VOIP  WITH 
SIMULTANEOUS  VOIP  SESSIONS  DEMONSTRATION  USING 

SJ PHONE 


The  instructions  contained  in  this  appendix  describe  how  to  setup  and 
demonstrate  a  SIP-based  VoIP  communication  using  the  network  topology  illustrated  in 
the  Figure  13.  In  this  test  scenario,  two  VoIP  communication  sessions  will  take  place 
simultaneously,  i.e.  one  between  Clients  A  and  C  and  the  other  between  Clients  B  and  D. 
Similar  to  the  previous  test,  the  DNAT  rule  is  purposely  taken  out  from  NAT  1 .  Packet 
captures  from  all  four  clients  are  included  at  the  end  of  this  appendix  along  with  their 
corresponding  analysis. 

A.  Network  Topology 

Refer  to  Figure  13  and  Figure  14  for  the  physical  and  logical  network  topology. 

B.  Equipment  Requirements 
B.  1 .  Clients  A,  B,  C,  and  D 

B .  1 . 1 .  Windows  XP  Operating  System 
B.1.2.  Soundcard 
B.1.3.  SJPhone  v.  1 .60 
B.1.4.  Ethereal 

B.  1 .5.  ZoneAlarm  (for  Clients  A  and  B  only) 

B.2.  NAT  1,  NAT  2,  NAT  3  and  Router 

B.2. 1 .  Linux  Operating  System  (Fedora  Core  4) 

B.2.2.  netfilter  and  iptables 
B.2.3.  Ethereal 

B.2.4.  Two  network  cards  (for  NAT  1,  NAT  2,  and  NAT  3) 

B.2.5.  Three  network  cards  (for  Router  only) 

B.3.  Additional  Equipment 

B.3. 1 .  Cross-over  cables  and  a  switch  or  hub  to  implement  the  network 
architecture  illustrated  in  Figure  13. 

B.3.2.  Microphones  as  audio  input  devices  for  clients  A,  B,  C  and  D 
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C.  Installation  and  Configuration 
C.l.  Client  A 

IP  Address:  131.120.9.16 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  131.120.9.15 
C.2.  Client  B 

IP  Address:  131.120.9.17 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  131.120.9.15 
C.3.  Clients  C  and  D 

IP  Address:  192.168.3.11 
Subnet  Mask:  255.255.255.0 
Default  Gateway:  192.168.3.1 
C.4.  Router 

C.4. 1 .  Configure  ethO  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethO  to 
include  the  following: 

DEVICE=eth0 
BOOTPROTO=NONE 
IPADDR=192. 168.100.27 
NETMASK=255. 255. 255.0 
GATEWAYS  92. 168. 100.88 
C.4.2.  Activate  ethO  by  running: 
ifup  ethO 

C.4.3.  Configure  ethl  by  editing /etc/sysconfig/network-scripts/ifcfg-ethl  to 
include  the  following: 

DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.202.1 
NETMASK=255. 255. 255.0 
C.4.4.  Activate  ethl  by  running: 
ifup  ethl 
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C.4.5.  Configure  eth2  by  editing  and  saving  /etc/sysconfig/network- 
scripts/ifcfg-eth2  to  include  the  following: 

DEVICE=eth2 
BOOTPROTO=NONE 
IPADDR=192. 168.2.1 
NETMASK=255. 255. 255.0 
C.4.6.  Activate  eth2  by  running: 
ifup  eth2 

C.4.7.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 
C.4.8.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
iptables  -t  nat  -F 

C.5.NAT  1 

C.5.1.  Configure  ethO  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethO  to 
include  the  following: 

DEVICE=ethO 
BOOTPROTO=NONE 
IPADDR=131. 120.9.15 
NETMASK=255. 255. 255.0 
C.5.2.  Activate  ethO  by  running: 
ifup  ethO 

C.5.3.  Configure  ethl  by  editing  and  saving  /etc/sysconfig/network- 
scripts/ifcfg-ethl  to  include  the  following: 

DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.100.88 
NETMASK=255. 255. 255.0 
C.5.4.  Activate  ethl  by  running: 
ifup  ethl 

C.5.5.  Configure  static  routes  by  running: 
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route  add  -net  192.168.202.0  netmask  255.255.255.0  gw  192.168.100.27  ethl 
route  add  -net  192.168.2.0  netmask  255.255.255.0  gw  192.168.100.27  ethl 
C.5.6.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 
C.5.7.  Flush  any  existing  firewall  and  NAT  rules  by  running: 
iptables  -F 
iptables  -t  nat  -F 

C.5.8.  Configure  NAT  rule  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  131 .120.9.15 

C.6.NAT  2 

C.6. 1 .  Configure  ethO  by  editing  and  saving  /etc/sysconfig/network- 
scripts/ifcfg-ethO  to  include  the  following: 

DEVICE=eth0 
BOOTPROTO=NONE 
IPADDR=196. 168.202.11 
NETMASK=255. 255. 255.0 
GATEWAY=  198. 168.202.1 
C.6.2.  Activate  ethO  by  running: 
ifup  ethO 

C.6.3.  Configure  ethl  by  editing  and  saving  /etc/sysconfig/network- 
scripts/ifcfg-ethl  to  include  the  following: 

DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.3.1 
NETMASK=255. 255. 255.0 
C.6.4.  Activate  ethl  by  running: 
ifup  ethl 

C.6.5.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 

C.6.6.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
iptables  -t  nat  -F 
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C.6.7.  Configure  NAT  rules  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  192.168.202.1 1 
iptables  -t  nat  -A  PREROUTING  -i  ethO  -j  DNAT  -to  192.1 68.3.1 1 

C.7.NAT  3 

C.7. 1 .  Configure  ethO  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethO  to 
include  the  following: 

DEVICE=ethO 
BOOTPROTO=NONE 
IPADDR=192. 168.2. 11 
NETMASK=255. 255. 255.0 
GATEWAY=  192. 168.2.1 
C.7.2.  Activate  ethO  by  running: 
ifup  ethO 

C.7.3.  Configure  ethl  by  editing /etc/sysconfig/network-scripts/ifcfg-ethl  to 
include  the  following: 

DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.3.1 
NETMASK=255. 255. 255.0 
C.7.4.  Activate  ethl  by  running: 
ifup  ethl 

C.7.5.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 
C.7.6.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
iptables  -t  nat  -F 

C.7.7.  Configure  NAT  rules  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  1 92.1 68.2.1 1 
iptables  -t  nat  -A  PREROUTING  -i  ethO  -j  DNAT  -to  192.1 68.3.1 1 
C.8.  SJPhone  Installation  and  Configuration 
C.8. 1 .  Clients  A,  B,  C  and  D 

C.8. 1.1.  Download  the  Windows  version  of  SJPhone  v.  1 .60  from  SJ  Tabs 
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C .  8 . 1 .2 .  Install  S  JPhone  v.  1 . 60 

C.8.1.3.  Launch  SJPhone 
C.8. 1 .4.  Right-click  on  SJPhone 
C.8.1.5.  Go  to  Services 
C.8.1.6.  Select  PC-to-PC  (SIP) 

C.9.  Ethereal  Installation  and  Configuration 
C.9. 1 .  Clients  A,  B,  C  and  D 

C.9.1.1.  Download  the  Windows  version  of  Ethereal  v.0.10.12 
C.9. 1 .2.  Install  Ethereal  v.0. 10. 12  by  following  on-screen  instructions 
C.9.2.  Router,  NAT  2  and  NAT  3 

C.9.2. 1 . 1 .  Install  Ethereal  if  it  is  not  already  installed 
C.9.2. 1.1.1.  Go  to  the  Desktop  menu 

C.9.2. 1 .1.2.  Go  to  System  Settings 

C.9.2. 1.1. 3.  Go  to  Add/Remove  Applications 

C.9.2. 1.1.4.  Click  on  Details  under  System  T ools 

C.9.2. 1.1. 5.  Find  and  then  check  ethereal-gnome 
C.9.2. 1.1. 6.  Click  on  Close 

C.9.2. 1.1. 7.  Click  on  Update 

C.9.2. 1 .1.8.  Put  in  the  correct  Fedora  Core  4  CDs  when 
prompted 

C .  1 0 .  ZoneAlann  Installation  and  Configuration 

C. 10.1. On  clients  A  and  B, 

C.  10. 1 . 1 .  Download  the  free  ZoneAlann  from  Zone  Labs 
C .  1 0 . 1.2 .  Install  ZoneAlann  by  following  on-screen  instructions 
C.  10. 1.3.  When  ZoneAlann  is  being  run  for  the  first  time,  it  will  ask  the  user 
to  choose  between  Basic  ZoneAlann  or  trial  version  of  ZoneAlann  Pro, 
select  the  trial  version  of  ZoneAlann 
C .  1 0 . 1 .4 .  Answer  on-screen  questions 
C.  10. 1.5.  Click  to  use  Trial  Version 

C.  10. 1 .6.  When  asked  to  select  a  security  level  for  the  detected  network, 
select  Allow  into  Trusted  Zone 
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C.  10. 1.7.  Allow  all  pop-ups  for  testing 
C .  1 0 . 1 . 8 .  Configure  firewall  rule  in  ZoneAlarm: 

C.  10. 1.8.1.  Go  to  Firewall  menu  on  the  left  panel 
C.  10. 1.8. 2.  Click  on  the  Expert  tab 
C.  10. 1.8.3. Click  on  Add 

C.  10. 1.8. 4.  Type  in  a  name  for  the  firewall  rule  in  the  Name  textbox 
C.  10. 1.8. 5. Under  Action,  select  Block 
C. 10. 1.8. 6. Under  Destination, 

C.  10.1. 8.6.1.  Select  Modify 

C.  10. 1.8. 6.2.  Select  Add  Location 

C. 10.1.8.6.3.  Select  IP  Address 

C.  10. 1.8. 6.4.  Type  in  a  description  in  the  Description  textbox 
C. 10. 1.8. 6. 5.  Type  192.168.3.11  in  the  IP  Address  textbox 

C. 10.1.8.6.6.  Click  OK 

C. 10.1.8.6.7.  Click  OK 

C. 10.1.8.6.8.  Click  Apply 

D.  Preparation  and  Testing 

D.  1 .  Adjust  volume  on  both  clients  accordingly 
D.2.  Plug  microphones  into  all  clients 
D.3.  On  Client  A, 

D.3. 1 .  Launch  Ethereal 
D.3.2.  Go  to  the  Capture  menu 
D.3.3.  Go  to  Interfaces 
D.3.4.  Click  on  Capture  131.120.9.16 
D.4.  On  Client  B, 

D.4. 1 .  Launch  Ethereal 
D.4.2.  Go  to  the  Capture  menu 
D.4.3.  Go  to  Interfaces 
D.4.4.  Click  on  Capture  131.120.9.17 
D.5.  On  Client  C  and  Client  D, 

D.5. 1 .  Launch  Ethereal 
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D.5.2.  Go  to  the  Capture  menu 
D.5.3.  Go  to  Interfaces 
D.5.4.  Click  on  Capture  192.168.3.11 
D.6.  On  Router, 

D.6.1.  Launch  one  instance  of  Ethereal 
D.6.1.1.  Go  to  the  Capture  menu 

D.6.1.2.  Go  to  Interfaces 

D.6.1.3.  Click  on  Capture  EthO 
D.6.2.  Launch  a  second  instance  of  Ethereal 
D.6.2.1.  Go  to  the  Capture  menu 

D.6.2.2.  Go  to  Interfaces 

D.6.2. 3.  Click  on  Capture  Eth  1 

D.6.3.  Launch  a  third  instance  of  Ethereal 
D.6.3.1.  Go  to  the  Capture  menu 

D.6.3.2.  Go  to  Interfaces 

D.6.3.3.  Click  on  Capture  Eth2 
D.7.0n  NAT  1,  NAT  2  and  NAT  3, 

D.7.1.  Launch  one  instance  of  Ethereal 
D.7.1.1.  Go  to  the  Capture  menu 

D.7.1.2.  Go  to  Interfaces 

D.7.1.3.  Click  on  Capture  EthO 
D.7.2.  Launch  another  instance  of  Ethereal 
D.7.2.1.  Go  to  the  Capture  menu 

D.7.2.2.  Go  to  Interfaces 

D.7.2.3.  Click  on  Capture  Eth  1 
D.8.  On  Client  C, 

D.8.1.  Call  A  by  dialing  131.120.9.16  in  SJPhone 
D.9.  On  Client  A, 

D.9. 1 .  Select  Accept  in  the  pop-up  dialog  box  when  SJPhone  rings 
D.9.2.  Clients  A  and  C  may  engage  in  a  VoIP  conversation  at  this  point. 
D.10.  On  Client  D, 
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D.  10.1. Call  B  by  dialing  131.120.9.17  in  SJPhone 
D.ll.  On  Client  B, 

D.  1 1 . 1  .Select  Accept  in  the  pop-up  dialog  box  when  SJPhone  rings 
D.  12.  Clients  B  and  D  may  engage  in  a  VoIP  conversation  at  this  point. 

D.  13.  Click  on  the  Hang-Up  bottom  on  either  SJPhone  to  terminate  call  when 

finished 

D.  14.  On  all  clients,  NATs  and  Router, 

D.  14. 1 .  Stop  packet  captures  selecting  Stop  on  Ethereal 
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E.  Packet  Captures 
E.  1 .  Client  A 

The  following  is  a  snapshot  of  the  packets  captured  on  Client  A  when  it  receives  a 
call  from  Client  C. 
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Figure  44.  Test  5;  Packet  Capture  on  Client  A 
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E.2.  Client  C 

The  following  is  a  snapshot  of  the  packets  captured  on  Client  C  when  it  calls 
Client  A. 
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Figure  45.  Test  5:  Packet  Capture  on  Client  C 
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E.3.  NAT  2  EthO 

The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface  (ethO)  of 
NAT  2. 


Figure  46.  Test  5:  Packet  Capture  on  ethO  of  NAT  2 
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E.4.  NAT  2  Ethl 

The  following  is  a  snapshot  of  the  packets  captured  on  the  second  interface  (ethl) 
of  NAT  2. 


Figure  47.  Test  5:  Packet  Capture  on  ethl  of  NAT  2 
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E.5.  Router  EthO 

The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface  (ethO)  of 
Router. 
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0010  08  00  06  04  00  01  00  eO  29  67  9e  9c  cO  a8  ca  0b  . )g. 

0020  00  00  00  00  00  00  cO  a8  ca  01  00  00  00  00  00  00  . 

0030  00  00  00  00  00  00  00  00  00  00  00  00  . 

File:  'f:/Router/Router  Ethl  (3  NAT)"  10SBKE  |P:  10507  0: 10507  M:  0 


Figure  48.  Test  5:  Packet  Capture  on  ethO  of  Router 
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E.6.  Router  Ethl 

The  following  is  a  snapshot  of  the  packets  captured  on  the  second  interface  (ethl) 
of  Router. 


Figure  49.  Test  5:  Packet  Capture  on  ethl  of  Router 
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E.7.  Router  Eth2 

The  following  is  a  snapshot  of  the  packets  captured  on  the  third  interface  (eth2)  of 
Router. 


Figure  50.  Test  5:  Packet  Capture  on  eth2  of  Router 
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E.8.  Client  B 

The  following  is  a  snapshot  of  the  packets  captured  on  Client  B  when  it  receives  a 
call  from  Client  D. 


Figure  5 1 .  Test  5:  Packet  Capture  on  Client  B 
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E.9.  Client  D 

The  following  is  a  snapshot  of  the  packets  captured  on  Client  D  when  it  calls 
Client  B. 


D  (3  NAT D  call  B)  -  Ethereal 

■hi 

File  Edit  View  Go  Capture  Analyze  Statistics  Help 

iiiii bi 

x  ®  {F  &  II  GU@lEiil^8i 

Filter: 

T  Expression,,,  Clear  Apply 

No,  •  Time  Source 

Destination 

Protocol 

Info 

* 

1  0.000000  192.168.3.11 

192.168.3.255 

browse  Domain/workgroup  Announcement  workgroup,  NT  workstation,  Domain  Enum 

2  62.740037  192.168.3.11 

192.168.3.255 

UDP 

Source  port:  5003  Destination  port:  5003 

3  182.74263' 192.168.3.11 

192.168.3.255 

UDP 

Source  port:  5003  Destination  port:  5003 

4  300.00140'  192.168.3.11 

192.168.3.255 

browse  Domain/workgroup  Announcement  workgroup,  nt  workstation,  Domain  Enum 

5  302.74519' 192.168.3.11 

192.168.3.255 

UDP 

Source  port:  5003  Destination  port:  5003 

6  333.58122'  192.168.3.11 

Broadcast 

ARP 

*o  has  192.168. 3.1?  Tall  192.168.3.11 

7  333.58139'  192.168.3.1 

192.168.3.11 

ARP 

192.168.3.1  is  at  00:0c:41:ef:af:be 

8  333.58141: 192.168.3.11 

131.120.9.17 

sip/sd  Request:  invite  sip:131.120.9.17,  with  session  description 

9  333.68377: 131.120.9.17 

192.168.3.11 

SIP 

status:  100  Trying 

10  333.90478'  131.120.9.17 

192.168.3.11 

SIP 

Status:  180  Ringing 

sip/sd  Status:  200  OK,  with  session  description 

12  336.43722' 192.168.3.11 

131.120.9.17 

SIP 

Request ;  ack  s1p:131.120.9.17:5060 

13  336.44499'  192.168.3.11 

131.120.9.17 

RTP 

Payload  type=GSM  06.10,  5SRC=295543i00,  Seq=54  2  3,  Tiie=0,  Mark 

14  336.462231 131.120.9.17 

192.168.3.11 

RTP 

Payload  type=GSM  06.10,  SSRC=568970784,  5eq=32283,  Ti«e=160 

15  336.46497:192.168.3.11 

131.120.9.17 

RTP 

payload  type-GSM  06.10,  SSRC=295i43500,  seq-5424,  Time*160 

16  336.48125'  131.120.9.17 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC=568970784,  Seq=32284,  Tine-320 

17  3  36.484  88  192.168.3.11 

131.120.9.17 

RTP 

Payload  type-GSM  06.10,  SSRC=295543500,  Seq-542  5,  Time=320 

18  336.50128: 131.120.9.17 

192.168.3.11 

RTP 

Payload  type>GSM  06.10,  SSRC-568970784,  Seq=32285,  Tine-480 

19  336.50487'  192.168.3.11 

131.120.9.17 

RTP 

Payload  type-GSM  06.10,  SSRC=295543500,  5eq»54  2  6,  Tine-480 

20  336.52139:131.120.9.17 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  S5RC=568970784,  Seq-32286,  Tine-640 

21  336.52489'  192.168.3.11 

131.120.9.17 

RTP 

Payload  type-GSM  06,10,  SSRC-295543500,  Seq-5427,  Time-640 

22  336.  54125'  131.120.9.17 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-568970784,  seq-32287,  Time-800 

23  336.54487'  192.168.3.11 

131.120.9.17 

RTP 

Payload  type-GSM  06.10,  SSRC-295543500,  Seq-54  2  8,  Time-800 

24  336.56173- 131.120.9.17 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-568970784,  Seq-32288,  Time-960 

25  336.56492;  192.168.3.11 

131.120.9.17 

RTP 

Payload  type-GSM  06.10,  SSRC-295543500,  seq-54  2  9,  Time-960 

26  336.58125;  131.120.9.17 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-568970784,  seq-32289,  Time-1120 

27  336.58495'  192.168.3.11 

131.120.9.17 

RTP 

Payload  type-GSM  06.10,  SSRC-295543500,  Seq-54  3  0,  Time-1120 

28  336.60140;  131.120.9.17 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-568970784,  Seq-32290,  Time-1280 

29  336.60488:192.168.3.11 

131.120.9.17 

RTP 

Payload  type-GSM  06.10,  SSRC-295543500,  Seq-5431,  Time-1280 

30  336.62125;  131.120.9.17 

192.168.3.11 

RTP 

Payload  type-GSM  06,10,  SSRC-568970784,  Seq-32291,  Time-1440 

31  336.62486: 192.168.3.11 

131.120.9.17 

RTP 

Payload  type-GSM  06,10,  SSRC-295543500,  Seq-54  3  2,  Time-1440 

32  336.64125: 131.120.9.17 

192.168.3.11 

RTP 

Payload  type-GSM  06,10,  SSRC-568970784,  seq-32292,  Time-1600 

V 

B  Frame  11  (700  bytes  on  wire,  700  bytes  captured) 

Ethernet  II,  Src:  192.168.3.1  (00:0c:41:ef :af :be),  Dst:  192.168,3.11  (00:0d:56:38:24:0c 
I  internet  Protocol,  Src:  131.120.9.17  (131.120.9.17),  Dst:  192.168.3,11  (192,168.3.11) 

B  user  Datagram  Protocol,  src  Port:  5060  (5060),  Dst  Port:  5060  (5060) 

B  session  Initiation  Protocol 
s  Status-Line:  sip/2.0  200  OK 
B  Message  Header 
B  Message  body 

B  session  Description  Protocol 

session  Description  Protocol  version  (v):  0 

■  owner/creator,  session  Id  (o):  -  3334649273  3334649273  IN  IP4 131.120.9.17 
session  Name  (s):  Slphone 

l  connection  information  (c):  IN  IP4 131.120.9.17 

■  Tine  Description,  active  tine  (t):  0  0 
B  session  Attribute  (a):  direction:active 

a  Media  Description,  riare  and  address  (m):  audio  49218  rtp/avp  3 101 
I  Media  Attribute  (a):  rtpnap:!  GSM/8000 

■  Media  Attribute  (a):  rtpmap:101  telephone-event/8000 

■  Media  Attribute  (a):  f«itp:101 0-11,16 


0000  00  Od  56  38  24  Od  00  Oc  41  ef  af  be  08  00  45  00  ..V8I...  A E. 

3010  02  ae  9d  4e  00  00  7d  11  4d  b4  83  78  09  11  cO  a8  ...N..).  M..x.... 

3020  03  0b  13  c4 13  c4  02  9a  cO  16  53  49  50  2f  32  2e  . SIP/2. 

3030  30  20  32  30  30  20  4f  4b  Od  0a  56  69  61  3a  20  53  0  200  OK  .  .Via:  S 

3040  49  50  2f  32  2e  30  2f  5!  44  50  20  31  39  32  2e  31  IP/2.0/U  DP  192.1 

AAXft  OR  70  In  77  In  71  71  7h  77  7ft  frf  77  7/1  7rl  7C  7ft  tO  3  11-  nnnrt.Cft 

File: "K:)Router/D (3 NAT D tall 8/  1172KB0I  |P:  11622 D:  11622  Mid 


Figure  52.  Test  5:  Packet  Capture  on  Client  D 
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E.10.  NAT  3  EthO 

The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface  (ethO)  of 
NAT  3. 


Figure  53.  Test  5:  Packet  Capture  on  ethO  of  NAT  3 


123 


E.l  1.  NAT  3  Ethl 

The  following  is  a  snapshot  of  the  packets  captured  on  the  second  interface  (ethl) 
of  NAT  3. 


•  NAT 3 Ethl  (3 NAT) -Ethereal 


File  Edit  View  Go  Capture  Analyze  Statistics  Help 


Hill  bfl  x  | 


Expression,,,  dear  Apply 


No.  •  i  Time 

Source 

Destination 

Protocol 

Info 

1  0.000000 

192.168.3.11 

Broadcast 

ARP 

who  has  192.168.3.1?  Tell  192.168.3.11 

2  0.000068 

localhost-2.  local 

192.168.3.11 

ARP 

192.168.3.1  is  at  00:01:02:89:97: 5b 

3  0.000258 

192.168.3.11 

131.120.9.16 

sip/sd  Request:  invite  sip:l3l.l20.9.l6,  with  session  description 

4  0.036591 

131.120.9.16 

192.168.3.11 

SIP 

status:  100  Trying 

5  0.313382 

131.120.9.16 

192.168.3.11 

SIP 

status:  180  Ringing 

6  5.035809 

localhost-2.  local 

192.168.3.11 

ARP 

Who  has  192.168.3.11?  Tell  192.168.3,1 

7  5.035913 

192.168.3.11 

localhost-2.  local 

ARP 

192.168.3.11  is  at  00:0f  :lf :18:d7:c5 

8  7.531550 

131.120.9.16 

192.168.3.11 

SIP/SD  status:  200  OK,  with  session  description 

9  7.538688 

192.168.3.11 

131.120.9.16 

SIP 

Request:  ACK  sip:131.120. 9.16:5060 

10  7.540704 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type=GSM  06.10,  S5RC-83818212,  Seq-29479,  Tine-0,  Hark 

11  7.560455 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83 818212,  Seq=29480,  Tine-160 

12  7.580429 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83 818212,  seq-29481,  Tine-320 

13  7.600478 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type=GSM  06.10,  SSRC-83  818212,  Seq-29482,  Tine-480 

14  7.604215 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-39818112,  Seq-5686,  Time=480 

15  7.620559 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC=83818212,  Seq-29483,  Tine-640 

16  7.624024 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-39818112,  Seq=5687,  Tine-640 

17  7.640452 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83 818212,  Seq-29484,  Tine-800 

18  7.644231 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type=GSM  06.10,  SSRC-39818112,  seq=5688,  Tine-800 

19  7.660483 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83 818212,  Seq=29485,  Time=960 

20  7.664027 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type=GSM  06.10,  SSRC-39818112,  Seq=5689,  Tine-960 

21  7.680503 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type=GSM  06.10,  S5RC-83  818212,  Seq-29486,  Tine-1120 

22  7.684027 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type=GSM  06.10,  5SRC=39818112,  Seq-5690,  Tine-1120 

23  7.700416 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83818212,  Seq-29487,  Tine-1280 

24  7.703990 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-39818112,  Seq-5691,  Tine-1280 

25  7.720429 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83818212,  Seq-29488,  Tine-1440 

26  7.724001 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-39818112,  Seq=5692,  Time=1440 

27  7.740431 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83 818212,  seq=29489,  Tine-1600 

28  7.744015 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-39818112,  Seq-5693,  Tine-1600 

29  7.760421 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type=GSM  06.10,  SSRC-83 818212,  Seq=29490,  Tine-1760 

30  7.763907 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type=GSM  06.10,  SSRC-39818112,  Seq-5694,  Tine-1760 

31  7.780415 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83 818212,  seq=29491,  Tine-1920 

32  7.783942 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-39818112,  Seq=i69i,  Tine-1920 

33  7.800415 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83 818212,  Seq-29492,  Tine-2080 

34  7.803931 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-39818112,  seq-5696,  Tine-2080 

35  7.820416 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83 818212,  Seq-29493,  Tine-2240 

36  7.823961 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-39818112,  Seq-5697,  Tine-2240 

37  7.840581 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83 818212,  Seq-29494,  Tine-2400 

38  7.843999 

131.120.9.16 

192.168.3.11 

RTP 

Payload  type-GSM  06.10,  SSRC-39818112,  Seq-5698,  Tine-2400 

39  7.860400 

192.168.3.11 

131.120.9.16 

RTP 

Payload  type-GSM  06.10,  SSRC-83 818212,  Seq-29495,  Tine-2560 

40  7.863907 

131.120.9.16 

192.168.3.11 

RTP 

Psulnad  rune-GS*  06.10.  SSRC-39R18117.  sen-5699.  Tine-2560 

9  Frame  10476  (60  bytes  on  wire,  60  bytes  captured) 

9  Ethernet  II,  src:  192.168.3.11  (00:0f :lf :18:d7:c5),  Dst:  Broadcast 
51  Address  Resolution  Protocol  (request) 


bOOQ 
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Figure  54.  Test  5:  Packet  Capture  on  ethl  of  NAT  3 
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E.12.  NATlEthO 

The  following  is  a  snapshot  of  the  packets  captured  on  the  first  interface  (ethO) 
NAT  1. 


Fie  Edit  View  Insert  Format  Help 


DtfHiEsW  ®  «  I 


16:25:49.519295 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.532642 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.539430 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.552142 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.559306 

IP 

131. 

120.9.15,49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.572149 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15,49284: 

UDP, 

length 

45 

16:25:49.579251 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16,49162: 

UDP, 

length 

45 

16:25:49.532311 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15,49284: 

UDP, 

length 

45 

16:25:49.599409 

IP 

131. 

120.9.15,49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.602181 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.619294 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.622193 

IP 

131. 

120.9.16,49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.639268 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.642178 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15,49284: 

UDP, 

length 

45 

16:25:49.659367 

IP 

131. 

120.9.15,49284 

> 

131.120. 

9.16,49162: 

UDP, 

length 

45 

16:25:49.662143 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.679254 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.682173 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.699316 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16,49162: 

UDP, 

length 

45 

16:25:49.702296 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.719246 

IP 

131. 

120.9.15,49284 

> 

131.120. 

9.16,49162: 

UDP, 

length 

45 

16:25:49.722171 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.739302 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.742157 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.759326 

IP 

131. 

120.9.15,49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.762154 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.779284 

IP 

131. 

120.9.15,49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.782164 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15,49284: 

UDP, 

length 

45 

16:25:49.799300 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.802151 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15,49284: 

UDP, 

length 

45 

16:25:49.819233 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.822164 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.839311 

IP 

131. 

120.9.15,49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.842186 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15,49284: 

UDP, 

length 

45 

16:25:49.859399 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16,49162: 

UDP, 

length 

45 

16:25:49.862166 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15,49284: 

UDP, 

length 

45 

16:25:49.879374 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.882136 

IP 

131. 

120.9.16,49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.899275 

IP 

131. 

120.9.15,49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.902156 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15,49284: 

UDP, 

length 

45 

16:25:49.919290 

IP 

131. 

120,9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.922157 

IP 

131. 

120.9.16,49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.939367 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:49.942159 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.959288 

IP 

131. 

120.9.15,49284 

> 

131.120. 

9.16,49162: 

UDP, 

length 

45 

16:25:49.962159 

IP 

131. 

120.9.16.49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.979303 

IP 

131. 

120.9.15,49284 

> 

131.120. 

9.16,49162: 

UDP, 

length 

45 

16:25:49.982129 

IP 

131. 

120.9.16,49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:49.999288 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16.49162: 

UDP, 

length 

45 

16:25:50.802150 

IP 

131. 

120.9.16,49162 

> 

131.120. 

9.15.49284: 

UDP, 

length 

45 

16:25:50.819301 

IP 

131. 

120.9.15.49284 

> 

131.120. 

9.16,49162: 

UDP, 

length 

45 

For  Help,  press  FI  NUM 


Figure  55.  Test  5:  Packet  Capture  on  ethO  of  NAT  1 
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E.13.  NATlEthl 

The  following  is  a  snapshot  of  the  packets  captured  on  the  second  interface  (ethl) 
of  NAT  1. 


B  NAT1JTH1  -  WordPad  gB® 


Fie  Edit  View  Insert  Format  Help 


16:25 

48.159372  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.162765  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.179344  IP  192.168.202.11.49284  >  131.120.9,16.49162 

UDP,  length  45 

16:25 

48.182812  IP  131.120.9.16,49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.199353  IP  192.168.202.11.49284  >  131,120.9,16.49162 

UDP,  length  45 

16:25 

48.202647  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.219377  IP  192.168.202.11.49284  >  131.120.9,16.49162 

UDP,  length  45 

16:25 

48.222740  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.239346  IP  192.168.202.11.49284  >  131,120.9.16.49162 

UDP,  length  45 

16:25 

48.242644  IP  131.120.9.16,49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.259403  IP  192.168.202.11.49284  >  131,120.9.16.49162 

UDP,  length  45 

16:25 

48.263320  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.279326  IP  192.168.202.11.49284  >  131,120.9,16.49162 

UDP,  length  45 

16:25 

48.282712  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.299348  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.302642  IP  131.120.9.16,49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.319350  IP  192.168.202.11.49284  >  131.120.9,16.49162 

UDP,  length  45 

16:25 

48.322634  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.339343  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.342645  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.359360  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.362641  IP  131.120.9.16,49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.379316  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.382695  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.399359  IP  192.168.202.11.49284  >  131,120.9.16.49162 

UDP,  length  45 

16:25 

48.403356  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.419355  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.422659  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.439336  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.442635  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.449382  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.462661  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.469315  IP  192.168.202.11.49284  >  131.120.9,16.49162 

UDP,  length  45 

16:25 

48.482654  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.489296  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.502612  IP  131.120.9.16,49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.509316  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.522668  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.529329  IP  192.168.202.11.49284  >  131,120.9,16.49162 

UDP,  length  45 

16:25 

48.543380  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.549307  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.562650  IP  131.120.9.16,49162  >  192.168.202,11.49284 

UDP,  length  45 

16:25 

48.569340  IP  192.168.202.11.49284  >  131.120.9.16.49162 

UDP,  length  45 

16:25 

48.582640  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.589308  IP  192.168.202.11.49284  >  131,120.9,16.49162 

UDP,  length  45 

16:25 

48.602626  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.609392  IP  192.168.202.11.49284  >  131.120.9,16.49162 

UDP,  length  45 

16:25 

48.622643  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.629316  IP  192.168.202.11.49284  >  131,120.9.16.49162 

UDP,  length  45 

16:25 

48.642640  IP  131.120.9.16.49162  >  192.168.202.11.49284 

UDP,  length  45 

16:25 

48.649372  IP  192.168.202.11.49284  >  131.120.9,16.49162 

UDP,  length  45 

For  Help,  press  FI  NUM  ' 


Figure  56.  Test  5:  Packet  Capture  on  ethl  of  NAT  1 
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E.14.  Analysis 

As  soon  as  Client  C  dialed  the  IP  address  of  A,  Client  C  sent  out  an  “INVITE” 
message  to  Client  A  (red  outline  in  Figure  44).  The  message  had  embedded  SDP 
information  to  infonn  Client  A  that  Client  C  would  be  sending  and  receiving  RTP 
packets  at  192.168.3.1 1  on  port  49284  (purple  outline  in  Figure  45).  To  acknowledge  the 
invitation,  Client  A  sent  a  “200  OK”  packet  to  Client  B  with  embedded  SDP  information 
indicating  that  it  would  send  and  receive  RTP  packets  at  131.120.9.16  on  port  49284 
(green  outline  in  Figure  44).  The  exchange  of  the  “INVITE”  and  “200  OK”  messages 
also  occurred  for  the  communication  between  Clients  B  and  D.  Client  D  informed  Client 
B  that  it  would  send  and  receive  RTP  packets  at  192.168.3.11  on  49162.  On  the  other 
hand,  Client  B  sent  and  received  RTP  packets  at  131.120.9.17  on  49128.  Figures  44 
shows  that  Client  A  sent  and  received  RTP  packet  directly  to/from  the  public  IP  address 
of  NAT  1 .  As  explained  in  Appendix  C,  S  JPhone  will  first  attempt  to  send  RTP  media 
packets  to  the  IP  address  indicated  in  the  SDP  messages  (or  the  private  IP  address  of 
Clients  C  and  D).  Since  the  firewall  rules  on  Client  A  and  Client  B  were  configured  to 
drop  packets  destined  to  the  private  IP  address  of  Clients  C  and  D,  none  of  the  initial 
packets  sent  out  by  Clients  A  or  B  could  reach  Clients  C  or  D.  Therefore,  Clients  A  and 
B  sent  subsequent  RTP  packets  to  the  IP  address  where  it  received  Client  C  and  D’s  RTP 
media  packets  from  (blue  outline  in  Figure  44).  The  packet  captures  on  Clients  C 
indicate  that  the  first  RTP  packet  in  the  communication  was  sent  by  Client  C.  Even 
though  NAT  1  was  not  explicitly  configured  to  rewrite  the  destination  IP  address  of 
incoming  packets  to  192.168.1.2  (public  IP  address  of  NAT  2),  NAT  1  was  able  to 
intelligently  detennine  this  because  iptables  has  a  mechanism  to  maintain  connection 
states  of  packets  that  are  initiated  from  the  local  network.  In  our  scenario,  when  the  first 
RTP  packet  sent  by  Client  C  reached  NAT  1,  the  packet  was  processed  get  changed  from 
192.168.202.11  to  192.168.120.9.  At  the  same  time,  NAT  1  created  an  entry  in  its 
connection  tracking  table  to  store  essential  infonnation  (such  as  source  and  destination  IP 
addresses  and  ports)  that  would  allow  it  to  associate  incoming  packets  with  Client  C. 
This  was  also  true  for  the  communication  between  Clients  D  and  B  (refer  to  Figures  49 
through  54). 
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APPENDIX  G.  TEST  6:  MYSEA  VOIP  CONFIGURATION 


The  objective  of  Test  6  is  to  confirm  that  the  MYSEA  server  could  support 
simultaneous  VoIP  sessions  from  multiple  MLS  LAN  clients.  As  described  in  Chapter 
IV,  each  network  interface  on  the  MLS  server,  currently  an  XTS-400,  currently  can  only 
have  one  static  route  entry.  However,  two  different  static  routes  are  needed  to  route 
packets  destined  for  Client  C  and  Client  D.  The  test  scenarios  described  here  were 
intended  to  be  workarounds  to  the  XTS-400  routing  problem.  The  goal  was  to  forward 
packets  to  the  Router  if  the  packets  were  received  on  the  single-level  interface  of  the 
MLS  server  or  forward  packets  to  the  NAT  1  if  the  packets  were  received  on  the  MLS 
LAN  interface  of  the  MLS  server.  In  other  words,  the  goal  was  to  configure  XTS-400  to 
forward  packets  to  its  adjacent  components,  namely  NAT  1  and  Router,  based  on  the 
network  interface  it  receives  the  packets.  Table  9  lists  network  configurations  that  were 
applied  to  the  MLS  server  for  the  four  test  scenarios. 


Test  Scenario 

Device  Name 

Gateway  Address 

1 

/dev/etherO 

192.168.0.27 

/dev/etherl 

192.168.100.88 

2 

/dev/etherO 

192.168.100.88 

/dev/etherl 

192.168.0.27 

3 

/dev/etherl 

192.168.100.88 

/dev/etherO 

192.168.0.27 

4 

/dev/etherl 

192.168.0.27 

/dev/etherO 

192.168.100.88 

Table  9.  Test  6:  Test  Scenario  Configurations 
After  each  set  of  network  configurations  was  applied  to  the  MLS  server,  the  Unix 
network  utility  ping  was  used  to  confirm  the  correctness  of  the  network  routing.  In 
particular,  each  of  the  four  IP  addresses  listed  in  Table  10  was  pinged  sequentially  for 
four  times  from  both  the  Router  and  NAT  1 .  Packets  were  captured  using  Ethereal  at  the 
MLS  LAN  interface  of  the  Router  (ethO,  192.168.0.27)  and  the  single-level  interface  of 
NAT  1  (ethl,  192.168.100.88)  for  post-test  analysis. 
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Interface 

Device 

IP  Address 

MLS  LAN  (ethO) 

MLS  server 

192.168.0.130 

sinqle-level  (ethl) 

MLS  server 

192.168.100.130 

sinqle-level  (ethl) 

NAT  1 

192.168.100.88 

public  (ethO) 

NAT  1 

131 .120.9.15 

Table  10.  Test  6:  Ping  Operations 


None  of  the  four  tests  was  completed  successfully,  i.e.,  there  was  at  least  one 
interface  on  the  MLS  server  and/or  the  public  NAT  that  the  Router  or  NAT  1  was  unable 
to  ping.  See  the  next  four  sections  for  the  results. 


A.  Network  Topology 

Refer  to  Figure  14  and  Figure  15  for  the  physical  and  logical  network  topology. 
Note  that  the  clients  and  NAT  3  were  not  used  in  the  test  scenarios. 

B.  Equipment  Requirements 

B .  1 .  NAT  1 ,  NAT  2  and  Router 

B .  1 . 1 .  Linux  Operating  System  (Fedora  Core  4) 

B.  1 .2.  nctliltcr  and  iptables 
B.1.3.  Ethereal 

B.1.4.  Two  network  cards  (for  NAT  1  and  NAT  2) 

B .  1 .5 .  Three  network  cards  (for  Router  only) 

B.2.  MLS  Server 
B.2.1.  XTS-400 

B. 3.  Additional  Equipment 

B. 3. 1 .  Cross-over  cables  and  a  switch  or  hub  to  implement  the  network 

architecture  illustrated  in  Figure  14. 

C.  Installation  and  Configuration 

C. l.  MLS  Server 

C.  1 . 1 .  Configure  two  network  interfaces  to  be  at  the  same  level  as  the  MLS  LAN 

by  entering: 

min  as  the  security  level 
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max  as  the  integrity  level 


C.2.  Router 

C.2. 1 .  Configure  ethO  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethO  to 
include  the  following: 

DEVICE=ethO 
BOOTPROTO=NONE 
IPADDR=192. 168.0.27 
NETMASK=255. 255. 255.0 
GATEWAY=1 92. 168.0. 130 
C.2.2.  Activate  ethO  by  running: 
ifup  ethO 

C.2.3.  Configure  ethl  by  editing /etc/sysconfig/network-scripts/ifcfg-ethl  to 
include  the  following: 

DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.202.1 
NETMASK=255. 255. 255.0 
C.2.4.  Activate  ethl  by  running: 
ifup  ethl 

C.2.5.  Configure  eth2  by  editing  and  saving  /etc/sysconfig/network- 
scripts/ifcfg-eth2  to  include  the  following: 

DEVICE=eth2 
BOOTPROTO=NONE 
IPADDR=192. 168.2.1 
NETMASK=255. 255. 255.0 
C.2.6.  Activate  eth2  by  running: 
ifup  eth2 

C.2.7.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 
C.2.8.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
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iptables  -t  nat  -F 


C.3.NAT  1 

C.3.1.  Configure  ethO  by  editing  /etc/sysconfig/network-scripts/ifcfg-ethO  to 
include  the  following: 

DEVICE=ethO 
BOOTPROTO=NONE 
IPADDR=131. 120.9.15 
NETMASK=255. 255. 255.0 
GATEWAY=1 31 .120.9.17 
C.3.2.  Activate  ethO  by  running: 
ifup  ethO 

C.3.3.  Configure  ethl  by  editing  and  saving  /etc/sysconfig/network- 
scripts/ifcfg-eth  1  to  include  the  following: 

DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.100.88 
NETMASK=255. 255. 255.0 
C.3.4.  Activate  ethl  by  running: 
ifup  ethl 

C.3.5.  Configure  static  routes  by  running: 

route  add  -net  192.168.202.0  netmask  255.255.255.0  gw  192.168.100.130  ethl 
route  add  -net  192.168.2.0  netmask  255.255.255.0  gw  192.168.100.130  ethl 
route  add  -net  192.168.0.0  netmask  255.255.255.0  gw  192.168.100.130  ethl 
C.3.6.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 
C.3.7.  Flush  any  existing  firewall  and  NAT  rules  by  running: 
iptables  -F 
iptables  -t  nat  -F 

C.3.8.  Configure  NAT  rule  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  131 .120.9.15 

C.4.NAT  2 
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C.4. 1 .  Configure  ethO  by  editing  and  saving  /etc/sysconfig/network- 
scripts/ifcfg-ethO  to  include  the  following: 

DEVICE=ethO 
BOOTPROTO=NONE 
IPADDR=196. 168.202. 11 
NETMASK=255. 255. 255.0 
GATEWAY=1 98. 168.202.1 
C.4.2.  Activate  ethO  by  running: 
ifup  ethO 

C.4.3.  Configure  ethl  by  editing  and  saving  /etc/sysconfig/network- 
scripts/ifcfg-eth  1  to  include  the  following: 

DEVICE=eth1 
BOOTPROTO=NONE 
IPADDR=192. 168.3.1 
NETMASK=255. 255. 255.0 
C.4.4.  Activate  ethl  by  running: 
ifup  ethl 

C.4.5.  Enable  IP  Forwarding  by  running: 

echo  1  >  /proc/sys/net/ipv4/ip_forward 

C.4.6.  Flush  any  existing  firewall  and  NAT  rules  by  running: 

iptables  -F 
iptables  -t  nat  -F 

C.4.7.  Configure  NAT  rules  by  running: 

iptables  -t  nat  -A  POSTROUTING  -o  ethO  -j  SNAT  -to  192.168.202.1 1 
iptables  -t  nat  -A  PREROUTING  -i  ethO  -j  DNAT  -to  1 92.1 68.3.1 1 
D.  Scenario  1 
D.l.  Description 

The  MFS  server  is  configured  in  order  as  follows:  any  packets  received  on  its 
MFS  FAN  (ethO,  192.168.0.130)  is  forwarded  to  the  MFS  FAN  interface  (ethO, 
192.168.0.27)  of  the  Router  and  any  packets  received  on  its  single-level  (ethl, 
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192.168.100.130)  is  forwarded  to  the  single-level  interface  (ethl,  192.168.100.88)  of 
NAT  1. 

D. 2.  Operations 

First,  NAT  2  pings: 

1 .  ethO  of  MLS  server 

2.  ethl  of  MLS  server 

3.  ethl  of  NAT  1 

4.  ethO  of  NAT  1 
Then,  Router  pings: 

5.  ethO  of  MLS  server 

6.  ethl  of  MLS  server 

7.  ethl  of  NAT  1 

8.  ethO  of  NAT  1 


D. 3. Network  Configuration  on  MLS  Server 

D.3. 1 .  Type  the  following  answers  when  prompted: 

SAK 


Enter  command?  tcpip _ edit 

Enter  editor  request? 

Enter  TCP/IP  daemon  name? 

Enter  TCPIP/IP  daemon  description? 

network 

Enter  domain  name? 

Enter  host  name? 

Enable  the  subnets  local  flag? 

Enable  the  IP  forwarding  flag? 

Enable  the  IP  send  redirect  flag? 

Enable  the  shutdown  on  failure  flag? 

Use  default  TCP  maximum  retransmission? 
Add  the  network  interface  configuration? 
Enter  TCP/IP  device  name? 

Enter  interface  address? 


add 

tcpipjmls 

TCP/IP  for  MLS  LAN 


cisrlabmlstestbedl  .com 

mlsserver 

n 

y 

y 

n 

y 

y 

/dev/etherO 

192.168.0.130 
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Enter  destination  address? 

Enter  broadcast  address? 

Enter  network  mask? 

Add  another  network  interface  entry? 
Enter  TCP/IP  device  name? 

Enter  interface  address? 

Enter  destination  address? 

Enter  broadcast  address? 

Enter  network  mask? 

Add  another  network  interface  entry? 
Add  the  route  configuration? 

Enter  TCP/IP  device  name 
Is  this  route  a  default  route 
Enter  destination  address 
Is  destination  address  a  host 
Enter  gateway  address 
Enter  route  metric 
Add  another  network  route  entry 
Enter  TCP/IP  device  name 
Is  this  route  a  default  route 
Enter  destination  address 
Is  destination  address  a  host 
Enter  gateway  address 
Enter  route  metric 
Add  another  network  route  entry 
Add  the  resolver  configuration? 

D. 4.  Preparation  and  Testing 
D.4.1.  On  NAT  1, 

D.4.1.1.  Launch  Ethereal 
D.4.1.2.  Go  to  the  Capture  menu 

D.4.1.3.  Go  to  Interfaces 
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0.0.0.0 

192.168.0.255 

255.255.255.0 

y 

/dev/etherl 

192.168.100.130 

0.0.0.0 

192.168.100.255 

255.255.255.0 

n 

y 

/dev/etherO 

n 

0.0.0.0 

n 

192.168.0.27 

1 

y 

/dev/etherl 

n 

0.0.0.0 

n 

192.168.100.88 

1 

n 

n 


D.4.1.4.  Click  on  Capture  192.168.100.88 
D.4.2.  On  Router, 

D.4.2. 1 .  Launch  Ethereal 

D.4.2.2.  Go  to  the  Capture  menu 

D.4.2.3.  Go  to  Interfaces 

D.4.2.4.  Click  on  Capture  1 92. 1 68.0.27 

D.4.3.  On  NAT  2, 

D.4.3. 1 .  Run  the  following  commands: 
ping  -c  4  192.168.0.130 
ping  -c  4  192.168.100.130 
ping  -c  4  192.168.100.88 
ping  -c  4  131 .120.9.15 
D.4.4.  Repeat  the  above  commands  on  the  Router 
D.4.5.  Stop  Ethereal  captures  on  both  NAT  1  and  Router 
D.  5.  Result 

Table  1 1  lists  the  result  of  the  Scenario  1.  The  first  column  shows  where  the 
ping  was  initiated  and  the  first  row  shows  what  hosts/IP  addresses  were  pinged. 
Neither  NAT  2  nor  the  Router  was  able  to  ping  the  public  interface  of  the  Public 


NAT. 
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Table  11.  Test  6:  Scenario  1  Result 
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D. 6.  Packet  Capture  when  pinged  from  NAT  2 
D.6.1.  Router 

The  following  two  figures  are  snapshots  of  the  packets  captured  on  ethO  of 
Router  when  the  four  interfaces  were  pinged  from  NAT  2. 


9 


Figure  57.  Test  6:  Scenario  1  Packet  Capture  on  Router  (pinged  from  NAT  2), 

Part  1 
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Figure  58.  Test  6:  Scenario  1  Packet  Capture  on  Router  (pinged  from  NAT  2), 

Part  2 
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D.6.2.  NAT  1 


The  following  is  a  snapshot  of  the  packets  captured  on  the  ethl  of  NAT  1 
when  the  four  interfaces  were  pinged  from  NAT  2. 


Figure  59.  Test  6:  Scenario  1  Packet  Capture  on  NAT  1  (pinged  from  NAT  2) 
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D.6.3.  Analysis 

NAT  2  was  able  to  ping  192.168.0.130  and  192.168.100.130  because  the 
MLS  server  shared  a  peer-to-peer  relationship  with  the  Router  and  the  Router  had  logic  to 
route  packets  between  the  MLS  server  and  NAT  2.  It  was  also  able  to  ping 
192.168.100.88  because  XTS-400  was  capable  of  routing  the  Echo  requests  and  replies  to 
its  immediate  peers  that  in  turn,  routed  the  packets  to  the  destination.  Pinging 
131. 120.9. 1 5  was  unsuccessful  from  NAT  2.  The  Router  saw  ICMP  requests  when  NAT 
2  pinged  131.120.9.15  (red  outline  in  Figure  57).  The  ICMP  requests  were  routed  from 
192.168.0.27  (yellow  outline  in  Figure  57)  to  192.168.0.130  (orange  outline  in  Figure 
57).  As  soon  as  the  MLS  server  received  the  requests,  the  XTS-400  bounced  them  back 
to  the  IP  address  from  which  they  came  (yellow  and  orange  outlines  in  Figure  58).  Note 
that  the  time-to-live  field  was  decremented  from  11  (green  outline  in  Figure  57)  to  10 
(green  outline  in  Figure  58)  indicating  that  the  two  requests  seen  in  the  packet  capture 
were,  in  fact,  the  same  packet.  This  sequence  of  events  continued  until  the  time-to-live 
was  exceeded  in  transit  (blue  outline  in  Figure  57).  Thus,  the  ICMP  was  never  able  to 
reach  NAT  1  as  shown  in  Figure  59. 
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D. 7.  Packet  Capture  when  pinged  from  Router 
D.7.1.  Router 

The  following  two  pictures  are  snapshots  of  the  packets  captured  on  ethO  of 
the  Router  when  the  four  interfaces  were  pinged  from  Router. 


-  start  CM'  i-  macaw  $ r9«w*At-Hr...  '<  .  t:»w 
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Figure  60.  Test  6:  Scenario  1  Packet  Capture  on  Router  (pinged  from  Router), 

Part  1 
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Figure  61.  Test  6:  Scenario  1  Packet  Capture  on  Router  (pinged  from  Router), 

Part  2 
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D.7.2.  NAT  1 

The  following  is  a  snapshot  of  the  packets  captured  on  the  NAT  1  when  the 
four  interfaces  were  pinged  from  Router. 


Figure  62.  Test  6:  Scenario  1  Packet  Capture  on  NAT  1  (pinged  from  Router) 


143 


D.7.3.  Analysis 

Figures  60  to  62  indicate  similar  behaviors  when  the  four  interfaces  were 
pinged  from  the  Router  instead  of  NAT  2.  The  Router  could  ping  192.168.0.130, 
192.168.100.130  and  192.168.100.88  for  the  reason  explained  in  D.6.3.  Pinging 
131.120.9.15  from  the  Router  had  a  different  behavior  than  the  one  seen  when  it 
was  pinged  from  NAT  2  such  that  the  Echo  requests  never  had  their  time-to-live 
exceeded.  Each  of  the  four  Echo  requests  was  routed  between  192.168.0.27  and 
192.168.0.130  twice  (yellow  and  orange  outlines  in  Figure  60  and  Figure  61). 
Each  request  was  routed  from  192.168.0.27  first  and  then  XTS-400  routed  it  back 
to  192.168.0.130  (Router)  as  soon  as  XTS-400  received  it.  The  decrement  in  the 
time-to-live  field  indicated  that  the  same  request  was  routed  back  and  forth  (green 
outlines  in  Figure  60  and  Figure  61).  The  request  was  not  routed  further  when  the 
Router  received  it  because  the  Router  recognized  its  own  packet  and  thus,  stopped 
routing  it.  As  a  result,  NAT  1  never  saw  the  Echo  requests  as  shown  in  Figure  62. 
Scenario  2 
E.  1 .  Description 

The  MLS  server  is  configured  in  order  as  follows:  any  packets  received  on  its 
MLS  LAN  interface  (ethO,  192.168.0.130)  is  forwarded  to  the  single-level  interface 
of  NAT  1  (ethl,  192.168.100.88)  and  any  packets  received  on  its  single-level 
interface  (ethl,  192.168.100.130)  is  forwarded  to  the  public  interface  of  Router  (ethO, 
192.168.0.27). 

E.2.  Operations 

First,  NAT  2  pings: 

1 .  ethO  of  MLS  server 

2.  ethl  of  MLS  server 

3.  ethl  of  NAT  1 

4.  ethO  of  NAT  1 

Then,  Router  pings: 

5.  ethO  of  MLS  server 

6.  ethl  of  MLS  server 

7.  ethl  of  NAT  1 


8.  ethO  of  NAT  1 


E.3.  Network  Configuration  on  MLS  Server 

E.3. 1 .  Type  the  following  answers  when  prompted: 

SAK 


Enter  command? 

Enter  editor  request? 

Enter  TCP/IP  daemon  name? 

Enter  TCPIP/IP  daemon  description? 

network 

Enter  domain  name? 

Enter  host  name? 

Enable  the  subnets  local  flag? 

Enable  the  IP  forwarding  flag? 

Enable  the  IP  send  redirect  flag? 

Enable  the  shutdown  on  failure  flag? 

Use  default  TCP  maximum  retransmission? 
Add  the  network  interface  configuration? 
Enter  TCP/IP  device  name? 

Enter  interface  address? 

Enter  destination  address? 

Enter  broadcast  address? 

Enter  network  mask? 

Add  another  network  interface  entry? 

Enter  TCP/IP  device  name? 

Enter  interface  address? 

Enter  destination  address? 

Enter  broadcast  address? 

Enter  network  mask? 

Add  another  network  interface  entry? 

Add  the  route  configuration? 

Enter  TCP/IP  device  name 


tcpip_edit 

add 

tcpipjmls 

TCP/IP  for  MLS  LAN 


cisrlabmlstestbedl  .com 

mlsserver 

n 

y 

y 

n 

y 

y 

/dev/etherO 

192.168.0.130 

0.0.0.0 

192.168.0.255 

255.255.255.0 

y 

/dev/etherl 

192.168.100.130 

0.0.0.0 

192.168.100.255 

255.255.255.0 

n 
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y 

/dev/etherO 


Is  this  route  a  default  route 
Enter  destination  address 
Is  destination  address  a  host 
Enter  gateway  address 
Enter  route  metric 
Add  another  network  route  entry 
Enter  TCP/IP  device  name 
Is  this  route  a  default  route 
Enter  destination  address 
Is  destination  address  a  host 
Enter  gateway  address 
Enter  route  metric 
Add  another  network  route  entry 
Add  the  resolver  configuration? 

E.4.  Preparation  and  Testing 
E.4.1.  On  NAT  1, 

E.4.1.1.  Launch  Ethereal 
E.4.1. 2.  Go  to  the  Capture  menu 

E.4.1. 3.  Go  to  Interfaces 

E.4.1. 4.  Click  on  Capture  192.168.100.88 
E.4.2.  On  Router, 

E.4.2. 1 .  Launch  Ethereal 
E.4.2. 2.  Go  to  the  Capture  menu 

E.4.2. 3.  Go  to  Interfaces 

E.4.2. 4.  Click  on  Capture  1 92. 1 68.0.27 
E.4.3.  On  NAT  2, 

E.4.3. 1 .  Run  the  following  commands: 

ping  -c  4  192.168.0.130 
ping  -c  4  192.168.100.130 
ping  -c  4  192.168.100.88 
ping  -c  4  131 .120.9.15 


n 

0.0.0.0 

n 

192.168.100.88 

1 

y 

/dev/etherl 

n 

0.0.0.0 

n 

192.168.0.27 

1 

n 

n 
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E.4.4.  Repeat  the  above  commands  on  the  Router 
E.4.5.  Stop  Ethereal  captures  on  both  NAT  1  and  Router 
E.5.  Result 

Table  12  lists  the  result  of  the  Scenario  2.  The  first  column  shows  where  the 
ping  was  initiated  and  the  first  row  shows  what  hosts/IP  addresses  were  pinged.  NAT 
2  was  unable  to  ping  any  of  the  four  IP  addresses. 


to 

from 

192.168.0.130 
(ethO,  MLS  LAN 
interface  of  MLS 
server) 

192.168.100.130 
(ethl ,  single-level 
interface  of  MLS 
server) 

192.168.100.88 
(ethl ,  single-level 
interface  of  NAT  1) 

131 .120.9.15 
(ethO,  public 
interface  of  NAT  1) 

NAT  2 

Failed 

Failed 

Failed 

Failed 

Router 

Successful 

Successful 

Successful 

Successful 

Table  12.  Test  6:  Scenario  2  Result 
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E.6.  Packet  Capture  when  pinged  from  NAT  2 
E.6.1.  Router 

The  following  is  a  snapshot  of  the  packets  captured  on  the  Router  when  the 
four  interfaces  were  pinged  from  NAT  2. 
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Figure  63. 


Test  6:  Scenario  2  Packet  Capture  on  Router  (pinged  from  NAT  2) 
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E.6.2.  NAT  1 

The  following  four  figures  are  snapshots  of  the  packets  captured  on  NAT  1 
when  the  four  interfaces  were  pinged  from  NAT  2. 


Figure  64.  Test  6:  Scenario  2  Packet  Capture  on  NAT  1  (pinged  from  NAT 

2),  Part  1 
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Figure  66.  Test  6:  Scenario  2  Packet  Capture  on  NAT  1  (pinged  from  NAT 

2),  Part  3 
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Figure  67. 


Test  6:  Scenario  2  Packet  Capture  on  NAT  1  (pinged  from  NAT  2), 

Part  4 


152 


E.6.3.  Analysis 

NAT  2  failed  to  ping  192.168.0.130  and  192.168.100.130..  Figure  63 
show  that  the  Router  did  not  see  any  Echo  replies  from  192.168.0.130  or 
192.168.100.130.  However,  it  is  evident  that  192.168.0.130  and  192.168.100.130 
replied  since  NAT  1  saw  them  (red  outline  in  Figure  64).  If  routing  was  done 
correctly,  the  Echo  replies  should  have  been  sent  to  the  Router  and  then  to  NAT  2 
instead  of  to  NAT  1.  Instead,  MLS  server  sent  the  Echo  replies  to  NAT  1.  Figure 
65  indicated  that  when  NAT  1  received  the  Echo  replies,  it  sent  them  to  next  hop 
(192.168.100.130)  based  on  its  routing  table  (yellow  and  orange  outlines  in  Figure 
65).  However,  XTS-400  forwarded  the  replies  back  NAT  1  at  192.168.100.88 
(yellow  and  orange  outlines  in  Figure  64).  Hence,  Echo  replies  were  bounced 
back  and  forth  between  192.168.100.130  and  192.168.100.88  until  the  time-to- 
live  field  reached  zero  (blue  outline  in  Figure  65).  This  sequence  of  events  also 
occurred  for  the  Echo  requests  from  192.168.202.11  to  192.168.100.130. 

NAT  2  also  failed  to  ping  192.168.100.88  and  131.120.9.15.  Figures  66 
and  67  show  that  there  exists  two  Echo  replies  for  each  Echo  request  destined  for 
192.168.100.88  and  131.120.9.15.  For  each  Echo  request  destined  for 
192.168.100.88,  NAT  1  responded  with  an  Echo  reply  which  is  sent  to  its  next 
hop  at  192.168.100.130  (orange  outline  in  Figure  66).  However,  the  same  Echo 
reply  was  bounced  back  by  XTS-400  to  where  it  came  from  when  XTS-400 
received  it  (yellow  and  orange  outline  in  Figure  67).  NAT  1  stopped  routing  the 
Echo  reply  further  since  it  recognized  its  own  packet.  This  explains  why  NAT  2 
was  never  able  to  receive  any  replies.  The  same  was  true  when  NAT  2  pinged 
131.120.9.15. 


153 


E.7.  Packet  Capture  when  pinged  from  Router 
E.7.1.  Router 

The  following  is  a  snapshot  of  the  packets  captured  on  the  Router  when  the 
four  interfaces  were  pinged  from  the  Router. 


Figure  68.  Test  6:  Scenario  2  Packet  Capture  on  Router  (pinged  from  Router) 
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E.7.2.  NAT  1 

The  following  is  a  snapshot  of  the  packets  captured  on  NAT  1  when  the  four 
interfaces  were  pinged  from  the  Router. 
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E. 7.3.  Analysis 

The  Router  was  able  to  ping  all  four  interfaces  described  in  D.2.  The 
Router  could  ping  192.168.0.130  because  it  shares  a  peer-to-peer  relationship 
with  the  MLS  server.  It  was  also  able  to  ping  192.168.100.130  because  XTS-400 
knew  its  interfaces.  The  same  logic  applied  to  the  case  when  the  Router  pinged 
192.168.100.88.  The  Router  successfully  pinged  131.120.9.15  in  this  scenario  but 
not  in  Scenario  1.  In  order  for  this  to  occur,  XTS-400  would  have  to  send  the 
Echo  requests  to  192.168.100.88  in  order  for  the  requests  to  reach  131.120.9.15. 
When  131.120.9.15  received  the  requests,  it  sent  Echo  replies  to  the  Router  by 
routing  the  packet  to  the  next  hop  or  the  MLS  server.  XTS-400  had  the  logic  to 
route  the  replies  to  the  Router  since  it  knew  its  peers. 

Scenario  3 
F.  1 .  Description 

The  MLS  server  is  configured  in  order  as  follows:  any  packets  received  on  its 
single-level  interface  (ethl,  192.168.100.130)  is  forwarded  to  the  single-level 
interface  of  NAT  1  (192.168.100.88)  and  any  packets  received  on  its  MLS  LAN 
interface  (192.168.0.130)  is  forwarded  to  the  public  interface  of  the  Router 
(192.168.0.27). 

F.2.  Operations 

First,  NAT  2  pings: 

1 .  ethO  of  MLS  server 

2.  ethl  of  MLS  server 

3.  ethl  of  NAT  1 

4.  ethO  of  NAT  1 

Then,  Router  pings: 

5.  ethO  of  MLS  server 

6.  ethl  of  MLS  server 

7.  ethl  of  NAT  1 

8.  ethO  of  NAT  1 

F.3.  Network  Configuration  on  MLS  Server 

F. 3. 1 .  Type  the  following  answers  when  prompted: 


SAK 

Enter  command? 

Enter  editor  request? 

Enter  TCP/IP  daemon  name? 

Enter  TCPIP/IP  daemon  description? 

network 

Enter  domain  name? 

Enter  host  name? 

Enable  the  subnets  local  flag? 

Enable  the  IP  forwarding  flag? 

Enable  the  IP  send  redirect  flag? 

Enable  the  shutdown  on  failure  flag? 

Use  default  TCP  maximum  retransmission? 
Add  the  network  interface  configuration? 
Enter  TCP/IP  device  name? 

Enter  interface  address? 

Enter  destination  address? 

Enter  broadcast  address? 

Enter  network  mask? 

Add  another  network  interface  entry? 

Enter  TCP/IP  device  name? 

Enter  interface  address? 

Enter  destination  address? 

Enter  broadcast  address? 

Enter  network  mask? 

Add  another  network  interface  entry? 

Add  the  route  configuration? 

Enter  TCP/IP  device  name 
Is  this  route  a  default  route 
Enter  destination  address 
Is  destination  address  a  host 


tcpipedit 
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Enter  gateway  address 
Enter  route  metric 
Add  another  network  route  entry 
Enter  TCP/IP  device  name 
Is  this  route  a  default  route 
Enter  destination  address 
Is  destination  address  a  host 
Enter  gateway  address 
Enter  route  metric 
Add  another  network  route  entry 
Add  the  resolver  configuration? 

F.4.  Preparation  and  Testing 
F.4.1.  On  NAT  1, 

F.4.1.1.  Launch  Ethereal 
F.4.1. 2.  Go  to  the  Capture  menu 

F.4.1. 3.  Go  to  Interfaces 

F.4.1. 4.  Click  on  Capture  192.168.100.88 

F.4.2.  On  Router, 

F.4.2. 1 .  Launch  Ethereal 
F.4.2. 2.  Go  to  the  Capture  menu 

F.4.2. 3.  Go  to  Interfaces 

F.4.2. 4.  Click  on  Capture  1 92. 1 68.0.27 

F.4.3.  On  NAT  2, 

FAG.  1 .  Run  the  following  commands: 
ping  -c  4  192.168.0.130 
ping  -c  4  192.168.100.130 
ping  -c  4  192.168.100.88 
ping  -c  4  131 .120.9.15 
F.4.4.  Repeat  the  above  commands  on  the  Router 
F.4.5.  Stop  Ethereal  captures  on  both  NAT  1  and  Router 
F.5.  Result 


192.168.100.88 
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/dev/etherO 
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0.0.0.0 
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192.168.0.27 
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n 
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Table  13  lists  the  result  of  the  Scenario  3.  The  first  column  shows  where 
the  ping  was  initiated  and  the  first  row  shows  what  hosts/IP  addresses  were  pinged. 
The  result  is  exactly  the  same  as  the  result  obtained  in  Scenario  2. 


Router  Successful 


192.168.100.130 
(ethl ,  single-level 
interface  of  MLS 
server) 

192.168.100.88 
(ethl ,  single-level 
interface  of  NAT  1) 

131 .120.9.15 
(ethO,  public 
interface  of  NAT  1) 

Failed 

Failed 

Failed 

Successful 

Successful 

Successful 

Table  13.  Test  6:  Scenario  3  Result 
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F.6.  Packet  Capture  when  pinged  from  NAT  2 
F.6.1.  Router 

The  following  is  a  snapshot  of  the  packets  captured  on  the  Router  when  the 
four  interfaces  were  pinged  from  NAT  2. 


Figure  70.  Test  6:  Scenario  3  Packet  Capture  on  Router  (pinged  from  NAT  2) 
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F.6.2.  NAT  1 

The  following  three  figures  are  snapshots  of  the  packets  captured  on  NAT  1 
when  the  four  interfaces  were  pinged  from  NAT  2. 


Figure  71.  Test  6:  Scenario  3  Packet  Capture  on  NAT  1  (pinged  from  NAT  2), 

Part  1 
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red 


Figure  72.  Test  6:  Scenario  3  Packet  Capture  on  NAT  1  (pinged  from  NAT  2), 

Part  2 
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F.6.3.  Analysis 

NAT  2  failed  to  ping  all  four  interfaces.  The  behaviors  seen  in  the  packet 
captures  in  this  section  are  identical  to  the  behaviors  seen  in  section  E.5.  All  the 
Echo  replies  (red  outline  in  Figure  71)  from  192.168.0.130  and  192.168.100.130 
were  bounced  between  192.168.100.130  and  192.168.100.88  (yellow  and  orange 
outlines  in  Figure  71  and  Figure  72).  As  a  result,  the  replies  never  reached  the 
Router  (Figure  70).  As  described  in  F.5,  every  Echo  request  destined  for 
192.168.100.88  and  131.120.9.15  had  two  Echo  replies  (red  outline  in  Figure  72). 
The  first  reply  went  from  192.168.100.88  to  192.168.100.130.  When  the  MLS 
server  received  the  reply,  the  XTS-400  routed  it  back  to  192.168.100.88.  This 
was  the  reason  for  seeing  two  Echo  replies  per  request.  Refer  to  E.6.3  for  more 
detail  explanation. 
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F.7.  Packet  Capture  when  pinged  from  Router 
F.7.1.  Router 

The  following  is  a  snapshot  of  the  packets  captured  on  the  Router  when  the 
four  interfaces  were  pinged  from  Router. 


Figure  74.  Test  6:  Scenario  3  Packet  Capture  on  Router  (pinged  from  Router) 
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F.7.2.  NAT  1 

The  following  is  a  snapshot  of  the  packets  captured  on  NAT  1  when  the  four 
interfaces  were  pinged  from  Router. 
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Figure  75.  Test  6:  Scenario  3  Packet  Capture  on  NAT  1  (pinged  from  Router) 
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G. 


F.7.3.  Analysis 

The  Router  was  able  to  ping  all  four  interfaces  as  described  in  F.2.  The 
behavior  of  this  scenario  is  identical  to  the  one  in  E.7.  Refer  to  E.7.3  for  a  more 
detail  analysis. 

Scenario  4 
G.l.  Description 

The  MLS  server  is  configured  as  follows  in  order:  any  packets  received  on  its 
single-level  interface  (ethl,  192.168.100.130)  is  forwarded  to  the  single-level 
interface  of  the  Router  (ethO,  192.168.0.27)  and  any  packets  received  on  its  MLS 
LAN  interface  (ethO,  192.168.0.130)  is  forwarded  to  the  single-level  interface  of  the 
NAT  1  (ethl,  192.168.100.88). 

G.2.  Operations 

First,  NAT  2  pings: 

1 .  ethO  of  MLS  server 

2.  ethl  of  MLS  server 

3.  ethl  of  NAT  1 

4.  ethO  of  NAT  1 
Then,  Router  pings: 

5.  ethO  of  MLS  server 

6.  ethl  of  MLS  server 

7.  ethl  of  NAT  1 

8.  ethO  of  NAT  1 


G. 3. Network  Configuration  on  MLS  Server. 

G.3. 1 .  Type  the  following  answers  when  prompted: 

SAK 


Enter  command? 

Enter  editor  request? 

Enter  TCP/IP  daemon  name? 

Enter  TCPIP/IP  daemon  description? 

network 

Enter  domain  name? 


tcpipedit 

add 

tcpipjmls 

TCP/IP  for  MLS  LAN 


cisrlabmlstestbedl  .com 
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mlsserver 


Enter  host  name? 

Enable  the  subnets  local  flag? 

Enable  the  IP  forwarding  flag? 

Enable  the  IP  send  redirect  flag? 

Enable  the  shutdown  on  failure  flag? 

Use  default  TCP  maximum  retransmission? 
Add  the  network  interface  configuration? 
Enter  TCP/IP  device  name? 

Enter  interface  address? 

Enter  destination  address? 

Enter  broadcast  address? 

Enter  network  mask? 

Add  another  network  interface  entry? 

Enter  TCP/IP  device  name? 

Enter  interface  address? 

Enter  destination  address? 

Enter  broadcast  address? 

Enter  network  mask? 

Add  another  network  interface  entry? 

Add  the  route  configuration? 

Enter  TCP/IP  device  name 
Is  this  route  a  default  route 
Enter  destination  address 
Is  destination  address  a  host 
Enter  gateway  address 
Enter  route  metric 
Add  another  network  route  entry 
Enter  TCP/IP  device  name 
Is  this  route  a  default  route 
Enter  destination  address 
Is  destination  address  a  host 


n 

y 

y 

n 

y 

y 

/dev/etherO 

192.168.0.130 

0.0.0.0 

192.168.0.255 

255.255.255.0 

y 

/dev/etherl 

192.168.100.130 

0.0.0.0 

192.168.100.255 

255.255.255.0 

n 

y 

/dev/etherl 

n 

0.0.0.0 

n 

192.168.0.27 

1 

y 

/dev/etherO 

n 

0.0.0.0 

n 
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Enter  gateway  address 
Enter  route  metric 
Add  another  network  route  entry 
Add  the  resolver  configuration? 
G. 4. Preparation  and  Testing 


192.168.100.88 

1 

n 

n 


G.4.1.  On  NAT  1, 

G.4.1.1.  Launch  Ethereal 
G.4.1.2.  Go  to  the  Capture  menu 
G.4.1.3.  Go  to  Interfaces 
G.4.1.4.  Click  on  Capture  192.168.100.88 
G.4.2.  On  Router, 

G.4.2. 1 .  Launch  Ethereal 
G.4.2.2.  Go  to  the  Capture  menu 
G.4.2.3.  Go  to  Interfaces 
G.4.2.4.  Click  on  Capture  1 92. 1 68.0.27 
G.4.3.  On  NAT  2, 

GAG.  1 .  Run  the  following  commands: 
ping  -c  4  192.168.0.130 
ping  -c  4  192.168.100.130 
ping  -c  4  192.168.100.88 
ping  -c  4  131 .120.9.15 
G.4.4.  Repeat  the  above  commands  on  the  Router 
G.4.5.  Stop  Ethereal  captures  on  both  NAT  1  and  Router 
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G.  5.  Result 

Table  14  lists  the  result  of  the  Scenario  4.  The  first  column  shows  where  the 
ping  was  initiated  and  the  first  row  shows  what  hosts/IP  addresses  were  pinged.  The 
result  from  Scenario  4  is  exactly  the  same  as  the  result  obtained  in  Scenario  1 . 


Table  14. 


Test  6:  Scenario  4  Result 
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G. 6.  Packet  Capture  when  pinged  from  NAT  2 
G.6.1.  Router 

The  following  is  a  snapshot  of  the  packets  captured  on  the  Router  when 
the  four  interfaces  were  pinged  from  NAT  2. 
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G.6.2.  NAT  1 

The  following  is  a  snapshot  of  the  packets  captured  on  the  NAT  1  when  the 
four  interfaces  were  pinged  from  NAT  2. 
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Figure  78.  Test  6:  Scenario  4  Packet  Capture  on  NAT  1  (pinged  from  NAT  2) 
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G.6.3.  Analysis 

Scenario  4  had  the  same  result  as  Scenario  1 .  In  other  words,  NAT  2  was 
able  to  ping  192.168.0.130,  192.168.100.130,  and  192.168.100.88  only.  It  failed  to  ping 
131.120.9.15.  The  Echo  request  destined  for  131.120.9.15  was  routed  from  192.168.0.27 
to  192.168.0.130  (yellow  and  orange  outlines  in  Figure  76).  However,  XTS-400 
forwarded  the  packet  back  to  192.168.0.27.  This  sequence  of  events  occurred  until  the 
time-to-live  exceeded.  As  a  result,  the  Echo  requests  never  reached  NAT  1  (Figure  77). 
Refer  to  D.6.3  for  more  details. 
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G. 7.  Packet  Capture  when  pinged  from  Router 
G.7.1.  Router 

The  following  is  a  snapshot  of  the  packets  captured  on  the  Router  when 
the  four  interfaces  were  pinged  from  Router. 


r-' 


Figure  79.  Test  6:  Scenario  4  Packet  Capture  on  Router  (pinged  from  Router), 

Part  1 
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Figure  80.  Test  6:  Scenario  4  Packet  Capture  on  Router  (pinged  from  Router), 

Part  2 
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G.7.2.  Router 

The  following  is  a  snapshot  of  the  packets  captured  on  the  NAT  1  when 
the  four  interfaces  were  pinged  from  Router. 


Figure  8 1 .  Test  6:  Scenario  4  Packet  Capture  on  NAT  1  (pinged  from  Router) 
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G.7.3.  Analysis 

The  Router  could  ping  both  interfaces  of  the  MLS  server  because  the 
Router  and  the  MLS  server  share  a  peer-to-peer  relationship.  The  Router  was  also 
able  to  ping  NAT  1  since  XTS-400  has  routing  capabilities  to  route  packets  to  its 
immediate  peers.  However,  pinging  131.120.9.15  was  unsuccessful.  Echo 
requests  destined  (red  outline  in  Figure  79)  for  131.129.9.15  were  sent  out  by  the 
Router  (yellow  and  orange  outlines  in  Figure  79).  However,  XTS-400  sent  those 
requests  back  to  the  Router  when  it  received  them  (yellow  and  orange  outlines  in 
Figure  80).  The  Router  stopped  routing  the  requests  further  as  it  recognized  them. 
Therefore,  the  Echo  requests  never  reached  NAT  1  (Figure  81). 

H.  Observation 

A  number  of  observations  can  be  made  from  analyzing  the  results  and  packet 
captures  for  the  four  scenarios.  First,  there  were  two  different  sets  of  results  from 
running  the  four  test  scenarios.  Scenarios  1  and  4  generated  the  first  set  and  scenarios  2 
and  3  have  generated  the  other  set  of  results  (refer  to  sections  D.5,  E.5,  F.5,  and  G.5). 
Second,  each  scenario  that  shared  the  same  gateway  address  sequence  in  its  routing 
configuration  yielded  identical  results.  In  other  words,  the  results  were  dependent  on  the 
order  of  the  gateway  address  and  were  independent  of  the  device  name  in  the  routing 
configuration  (refer  to  Table  9).  Third,  XTS-400  seemed  to  always  forward  packets 
destined  for  unknown  networks  to  the  gateway  indicated  in  the  first  static  route  in  its 
routing  table.  In  scenarios  1  and  4,  XTS-400  bounced  Echo  requests  it  received  from 
131.120.9.15  to  192.168.0.27  instead  of  forwarding  them  onto  NAT  1.  Also  in  scenarios 
1  and  4,  similar  behavior  of  XTS-400  forwarding  packets  to  192.168.0.27  was  seen  when 
the  Router  pinged  131.120.9.15.  In  both  cases,  the  XTS-400  did  not  have  routing 
information  for  the  131. 120.9.x  network  and  the  gateway  for  its  first  static  route  is 
192.168.0.27.  The  XTS-400  always  routed  packets  destined  for  unknown  networks  to 
192.168.100.88  instead  in  scenarios  2  and  3  where  the  192.168.100.88  was  the  gateway 
in  its  first  static  route. 
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